Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread David Lang
You may be right that OpenWRT is doomed, but we have seen time and time again 
that OpenSource software is not a zero-sum game.


Yes, if OpenWRT does nothing, it will struggle, but that's unlikely to be the 
case.


For that matter, even with no new manpower, OpenWRT could just copy everything 
that LEDE does and still survive for a long time based on brand recognition 
(after all, people are still downloading OpenOffice, and that hasn't even been 
pulling improvements from LibreOffice)


There's no question that there is going to be disruption and a loss of progress 
in the short term, but before you count either side out, let them stabilize, and 
figure out what's really important to them going forward.


Revisit the question in 6-9 months and things will probably be much clearer.

Remember that the remaining OpenWRT folks haven't has weeks or months to plan 
what to do at this point. It will take them time for them to figure out what's 
going to end up happening. In the short term, they have to plug the holes and 
figure out if anything critical needs to be done to keep the lights on. Only 
after they are able to get past this short term crisis will they be able to 
really think about the larger issues and figure out what to do about them.


And the LEDE folks have a lot of infrastructure to setup (and there will be a 
lot of bikeshedding going on while they do this), so they are going to take some 
time to get everything going and get a release out.


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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Luiz Angelo Daros de Luca
I like to take decisions based more on "Realpolitik" than on
ideology/feelings. I have no side and no feelings for any of people
involved. I just want to have a good router distribution.

What is a OSS project? It is the sum of work of people. So, the future of a
project lies on how much people will work on it.

Let's face: if you sum the commits count* of those leaving, you start to
worry about OpenWRT:

Core:
 10815 nbd <<
  4531 juhosg
  3649 blogic <<
  3436 florian
  2654 nico
  2183 jow <<
  1482 kaloz
  1414 hauke <<
   925 wbx
   718 cyrus <<

Packages:
  512 Steven Barth <<
   469 Ted Hess <<
   256 Marcel Denia
   250 Daniel Golle <<
   235 Nikos Mavrogiannopoulos
   230 sbyx
   214 Hannu Nyman
   202 Alexandru Ardelean
   162 Jo-Philipp Wich <<
   154 Nicolas Thill
(git shortlog -s -n | head -10)

*yes, I know that they are not the author of all commits but they were the
ones that reviewed the patches and committed them.

If you lose most of the committers, the project will REALLY lag behind, to
a point of losing its self sustainability. Those leaving represents more
than 50% of commits of all time and, since 2014, they are the top 6 devs
with more than 80% of commits.
(git shortlog -s -n 3328763a8d0abbcbcf79b5a91e6abbb0b55b3119..HEAD  | head
-10)
They are(were) the ones currently working.

One of the complaints was that there were no process of introducing new
devs. So, when a bunch of them leave, what will happen? Ease the process of
including new devs (which is one of the demanded changes)? Do we really
think that there is a suppressed supply of developers wanting to replace
the leaving devs?

It seems that the decision power in OpenWRT does not match the amount of
work each one is currently dedicating to the project.

What might happen with the fork?

OpenWRT loses 80% of its development power (not counting those that leave
to LEDE after).
LEDE might attract more devs with an open politic (as packages are much
better at github). In the end, if LEDE succeeds on balance more devs,
stability and new resources, everybody will use it and OpenWRT will start
to rot. If it fails, both projects might die and everybody loses.

This was already happened with OpenOffice/LibreOffice (I guess with
ffmpeg/libav less devs left). They created a new project because of
disagreement (with Oracle). Devs flew to the new project. The old one
started to rot and ended dropped to the community. I guess most of the
current downloaders of OpenOffice do not know LibreOffice and they are not
power users. With OpenWRT, most of downloaders are power users.

You can replace infrastructure in a matter of weeks. Replace a brand in
months. However, you need years or decades to form a development team.

What are the options for OpenWRT Decision Team (as the development team
just left)?

1) Do nothing. Let LEDE take its chances. If it succeed, it will take the
place of OpenWRT and OpenWRT will rot. If not, we'll might have a version
of mutual assured destruction.

2) The remaining OpenWRT Core Team accept some (or all) terms of the LEDE
Team. Face it. There were already most of the "OpenWRT Core Team". Now give
them the corresponding decision power.

Even if all the remaining of the OpenWRT Core Team resign now and give all
the control to LEDE, OpenWRT will be less affected than the current
situation.

If I felt that my position would put in danger a project on which I
dedicated and care so much, I would rather simply resign than let my work
be gone. OpenWRT should be more than someone's project. However, there is
no need to anyone to leave but a need of power transferring.

The ones with current decision power at OpenWRT will either give away some
of its power or they will lose it all (in favor of a rebooted OpenWRT
leaded by LEAD or because it simply became irrelevant).

Regards,
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Scrap that, David makes sense (was Re: A request for more clarity on the fork)

2016-05-05 Thread Daniel Dickinson
Below is the message referenced in the previous email, so that it makes
more sense, but please remember:

> Add to this that with years of toxic arguments (as acknowledged by both
> sides) behind this, there's likely to be too much acrimony in
> explanations given.
>
> Much as not knowing is something I personally have hard time with, and
> others have complained of, sometimes it's better to just put that
> behind, and move forward in a constructive way.

Hi all,

I know other community members of complained about the lack of
information about the reasons for the fork (they and I don't think
LEDE's official announcement really provides enough information to
really understand the situation) and I especially do badly in a vacuum -
I tend to strain to find answers and don't necessarily come up with the
right one(s) (that was also why I had such an amount of trouble with
patches not getting a response, previously).

In any event a great many of us would like to have a clearer picture of
what lead up to the split, and more complete reasoning for why the
problems couldn't be resolved within the current openwrt structure.

I've had guesses but now I'm second guessing my guesses, and really it
shouldn't be a guessing game, particularly since both sides claim to be
interested in transparency and the best interests of the community.

C'mon, can we have more than political statements, please?

On 16-05-05 11:42 PM, Daniel Dickinson wrote:
> I think David Lang makes a lot of sense; it took years to reach this
> point, better to carry on independently, but working together as much as
> can be managed, and let time both settle the dust and demonstrate which
> ideas really pan out.
> 
> Add to this that with years of toxic arguments (as acknowledged by both
> sides) behind this, there's likely to be too much acrimony in
> explanations given.
> 
> Much as not knowing is something I personally have hard time with, and
> others have complained of, sometimes it's better to just put that
> behind, and move forward in a constructive way.
> 
> Regards,
> 
> Daniel
> ___
> 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] [OpenWrt] #20982: jffs2-error / nanostation M5 xw / r47658

2016-05-05 Thread Bill Moffitt

On 05/05/16 19:16, OpenWrt wrote:

#20982: jffs2-error / nanostation M5 xw / r47658
+
   Reporter:  bittorf@…  |  Owner:  developers
   Type:  defect | Status:  new
   Priority:  normal |  Milestone:
  Component:  packages   |Version:  Trunk
Resolution: |   Keywords:
+

Comment (by johnv):

  Replying to [comment:31 bmoffitt]:

  > 1.) Recovery (tftp) flash AirOS 5.6.3 onto the radio; then
  > 2.) Using the fwupdate command in AirOS, flash AirOS 5.5.11 onto the
  radio; then
  > 3.) Again using the fwupdate command, flash OpenWRT onto the radio.
  >
  > This sequence seems to work on every PicoStation and NanoStation Loco M2
  XM I have gotten SO FAR. Oddly, downgrading a radio that came with AirOS
  5.6 running on it to AirOS 5.5 DID NOT WORK - it appears that it is
  necessary to do the recovery (tftp) flash of AirOS 5.6 before you
  downgrade to 5.5. I honestly cannot explain it, but, so far, this sequence
  seems the only way to reliably flash OpenWRT onto a PicoStation, Bullet,
  or NanoStation Loco M2 that comes running AirOS 5.6.


  Can you confirm the 5.6.X version that was installed on the units when you
  received them?  There is a Fix in the UBNT changelog for 5.6.4:

  - Fix: After FW downgrade to 5.5.6 device goes to read-only state (TFTP
  recovery to previous airOS version is required to restore normal
  operation)


  So wondering if the ones that you have that you are unable to simply
  downgrade back to 5.5.11, are prior to 5.6.4 or not.  And if so, if you
  could upgrade to 5.6.4, then downgrade to 5.5.11, and the OpenWRT.
  Getting messier but still might be easier then tftp.
Alas, I don't have any new ones at the moment, and probably won't for a 
few weeks. And I don't recall what the new ones I was testing came with.


--
Ticket URL: 
OpenWrt 
Opensource Wireless Router Technology


--
Bill Moffitt
Ayrstone Productivity
http://ayrstone.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] Scrap that, David makes sense (was Re: A request for more clarity on the fork)

2016-05-05 Thread Daniel Dickinson
I think David Lang makes a lot of sense; it took years to reach this
point, better to carry on independently, but working together as much as
can be managed, and let time both settle the dust and demonstrate which
ideas really pan out.

Add to this that with years of toxic arguments (as acknowledged by both
sides) behind this, there's likely to be too much acrimony in
explanations given.

Much as not knowing is something I personally have hard time with, and
others have complained of, sometimes it's better to just put that
behind, and move forward in a constructive way.

Regards,

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


[OpenWrt-Devel] A request for more clarity on the fork

2016-05-05 Thread Daniel Dickinson
Hi all,

I know other community members of complained about the lack of
information about the reasons for the fork (they and I don't think
LEDE's official announcement really provides enough information to
really understand the situation) and I especially do badly in a vacuum -
I tend to strain to find answers and don't necessarily come up with the
right one(s) (that was also why I had such an amount of trouble with
patches not getting a response, previously).

In any event a great many of us would like to have a clearer picture of
what lead up to the split, and more complete reasoning for why the
problems couldn't be resolved within the current openwrt structure.

I've had guesses but now I'm second guessing my guesses, and really it
shouldn't be a guessing game, particularly since both sides claim to be
interested in transparency and the best interests of the community.

C'mon, can we have more than political statements, please?

Regards,

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


Re: [OpenWrt-Devel] Calmer heads than mine...

2016-05-05 Thread David Lang
I also think that it is utterly unreasonable to think that the differences are 
going to be resolved in the next few days/weeks. It took years to get to this 
point, and there are some very significant differences of opinion. There is 
going to need to be time for one side or the other to be proven right/wrong on 
various issues, and that is only going to happen with months/years of producing 
and maintaining the codebases.


The licenses allow both projects to pull from the other, so most of the hard 
technical work will end up being shared in practice.


The infrastructure and organizational work is a duplication of effort, but since 
that's where there is a lot of disagreement over the best way to do things, I 
think this is useful duplication, let time show which elements of each team's 
ideas work well.


I think the key thing right now is to keep the split from becoming toxic the way 
it sometimes has with other projects. If people can calm down enough to let the 
split become reasonably friendly, then I think a merge in a year or two would be 
a real possibility, with the resulting organization being stronger for trying 
the different approaches.


I was surprised and bothered by the extent of the posts announcing LEDE on so 
many different openwrt mailing lists and forum threads, and I was bothered by 
the OpenWRT response of shutting off the e-mail. The LEDE people still maintain 
some of the OpenWRT infrastructure and have said that they are willing to keep 
doing so.


So now that both sides have stepped on each other's toes, can everyone take a 
deep breath and look forward.


OpenWRT needs to fill holes left by the departing people, and think about what 
truth there is in their complaints, and plan how to deal with them while still 
maintaining progress.


LEDE needs to get infrastructure setup, make a release, and show that they can 
maintain it and respond to bug reports.


Let's let everyone get to work rather than defending themselves or lashing out 
at the other side, and see how things go over the next several months.


David Lang

On Thu, 5 May 2016, Daniel Dickinson wrote:


Hi all,

Sorry for sounding off so much yet again.  I've been trying to interpret
events with a severe lack of information and have unfavourable guesses
and impressions that may or may not be accurate.

I do know that some of the developers have a history of not getting
along, and that has hurt the project.  I also know that there are
members of both sides who are frustratingly obstinate and/or
antagonistic or downright nasty to people they disagree with.

Which is why I'm not sure this rift can be healed.  I think it would be
good if the saner elements (which is not me; I'm not on either side and
I'm too impetuous and ready to make noise) who I think are the majority
from both sides would communicate and come to an agreement that they
imposed on the less reasonable elements of the groups they are currently
part of.

I think the calmer elements have gotten caught up in or the other of the
less reasonable types battles, and that if the calmer elements could get
it together it would benefit the community as a whole

Regards,

Daniel
___
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] Calmer heads than mine...

2016-05-05 Thread Daniel Dickinson
Hi all,

Sorry for sounding off so much yet again.  I've been trying to interpret
events with a severe lack of information and have unfavourable guesses
and impressions that may or may not be accurate.

I do know that some of the developers have a history of not getting
along, and that has hurt the project.  I also know that there are
members of both sides who are frustratingly obstinate and/or
antagonistic or downright nasty to people they disagree with.

Which is why I'm not sure this rift can be healed.  I think it would be
good if the saner elements (which is not me; I'm not on either side and
I'm too impetuous and ready to make noise) who I think are the majority
from both sides would communicate and come to an agreement that they
imposed on the less reasonable elements of the groups they are currently
part of.

I think the calmer elements have gotten caught up in or the other of the
less reasonable types battles, and that if the calmer elements could get
it together it would benefit the community as a whole

Regards,

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Luka Perkov
>On 2016-05-05 20:22, mbm wrote:
>> On 5/5/2016 7:40 AM, Felix Fietkau wrote:
>>> Many of the changes that we previously tried to introduce were often 
>>> squashed by internal disagreements. Resulting discussions often turned 
>>> toxic quickly and led to nothing being done to address the issues. 
>>> Setting up the LEDE project was our way of creating a testbed for 
>>> changes that we believe are important for the survival of the project. 
>>
>> Change is not easy. Discussions need to happen. The problem is simply
>> kicking out people you didn't agree with by starting a new organization
>> in secret; you've created the public perception that we're somehow
>> against you when really we all want the same things.
>
> Years of internal discussion led nowhere. Maybe it helps now that we're
> making the whole issue public.

For the sake of transparency, we've had public discussions, about a number of
things, for example switching to Git:

- https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html
- https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036480.html
- https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036486.html
- https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036500.html

And based on these inputs from you the switch was not made even though several
OpenWrt developers wanted to switch.

Also, server outages can happen to anybody:
- https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/038547.html

However, we do not want to point fingers. What we do want is to make a great
community around OpenWrt and to drive innovation - just like it has been done
for more then a decade now. 

There has been a long history - mostly good, sometimes bad - since the project
started from a garage project, to now having a project used by an awesome
amount of users. This can be seen from the constructive discussions in this
list on a daily basis, and in this very thread. Also, the project is used as
the main SDK by many silicon vendors internally, and by vast number of
companies on the embedded market.

We are open for a discussion and would like to keep the OpenWrt's and it's
community interests in the first place. Splitting the project does not make
sense. Do you agree?

>>> We appreciate your effort to have an open discussion about this, 
>>> however the sudden deletion of our widely published openwrt.org email 
>>> addresses somewhat undermines this. We will not respond in kind and we 
>>> will continue to maintain the critical parts of OpenWrt infrastructure 
>>> that we control.
>>
>> Let's be clear on this subject; no commit access was revoked, you still
>> have full read and write access to the entire OpenWrt tree.
>>
>> Email forwarding was temporarily disabled following the LEDE announcement
>> - LEDE's own rules prohibit project based email addresses
> No, they don't. They state that the LEDE project won't provide project
> email addresses. Interpreting that as meaning that we shouldn't be able
> to access our openwrt.org addresses is more than a bit of a stretch.

In any case, due to the events that happened and the fact that the OpenWrt name
is being used in a manner opposite of the projects best interest, we felt that
these actions were needed in order to avoid the further damages to the project.

>> - It's unclear if LEDE still represents OpenWrt
> So? Asking us to not send any further emails about LEDE from our
> openwrt.org addresses should have been enough.

Actually, this was discussed on #lede-adm.

>> My hope is that this whole LEDE vs OpenWrt situation can be resolved.
> I hope so too.

That is good to hear. Bringing the issue to a more public discussion might
speed up resolving them, but it is in everyone's best interest to get them
resolved.

Since so far there has not been a presented reason why the proposals made could
not be incorporated in main OpenWrt as well it still remains unclear what
benefits brings splitting the project. I propose we work together to come up
with a unified solution that all the community will benefit from.

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


Re: [OpenWrt-Devel] [PATCH v4 1/4] mvebu: add squashfs image type to MMCProfile

2016-05-05 Thread Josua Mayer
Hi Andrej,

First let me thank you for taking the time to review my proposals!

Am 06.05.2016 um 02:04 schrieb Andrej Vlasic:
> Hi Josua,
> 
> On 04.05.2016 21:24, josua.maye...@gmail.com wrote:
>> From: Josua Mayer 
>>
>> Added gen_mvebu_sdcard_img.sh to create bootable sdcard images. It takes
>> the bootloader and partition images to create a bootable sdcard image.
>>
>> Partition Layout:
>> p1: fat32: for kernel, dtb and boot config files if any
>> p2: squashfs: for openwrt
>>
>> This change is developed for the Clearfog, but should work on all A38x
>> SoCs that can boot from mmc.
>>
>> Signed-off-by: Josua Mayer 
>> ---
>>  target/linux/mvebu/image/Makefile|  16 
>>  target/linux/mvebu/image/gen_mvebu_sdcard_img.sh | 100
>> +++
>>  tools/Makefile   |   1 +
>>  3 files changed, 117 insertions(+)
>>  create mode 100755 target/linux/mvebu/image/gen_mvebu_sdcard_img.sh
>>
>> diff --git a/target/linux/mvebu/image/Makefile
>> b/target/linux/mvebu/image/Makefile
>> index cb73c3b..fc5fded 100644
>> --- a/target/linux/mvebu/image/Makefile
>> +++ b/target/linux/mvebu/image/Makefile
>> @@ -107,6 +107,9 @@ define MMCProfile
>>  ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
>>  $(call Image/Build/Profile,$(1)/Initramfs)
>>  endif
>> +ifneq ($(CONFIG_TARGET_ROOTFS_SQUASHFS),)
>> +$(call Image/Build/squashfs)
>> +endif
>>endef
>>
>>define Image/Build/Profile/$(1)/Initramfs
>> @@ -114,6 +117,19 @@ define MMCProfile
>>  cp $(KDIR)/uImage-initramfs-$(2)
>> $(BIN_DIR)/$(IMG_PREFIX)-$(2)-initramfs
>>endef
>>
>> +  define Image/Build/Profile/$(1)/squashfs
>> +$(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
>> +cp $(KDIR)/root.squashfs $(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs
>> +rm -f $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32
>> +mkfs.fat -C $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(shell echo
>> $$((4*1024)) # 4MB)
>> +mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(KDIR)/zImage ::
>> +mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32
>> $(DTS_DIR)/$(2).dtb ::
>> +./gen_mvebu_sdcard_img.sh
>> "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-squashfs-sdcard.img" \
>> +   
>> "$(BIN_DIR)/uboot-mvebu-clearfog/openwrt-mvebu-clearfog-u-boot-spl.kwb" \
>> +c "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32" \
>> +83 "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs"
>> +  endef
>> +
> 
> Image generation script here requires u-boot binary to exist, but what
> if one doesn't select u-boot to be generated? It would be better to
That would certainly be a problem.
> exclude it from generated sdcard image, it can be flashed anyway with dd
> to beginning of the sd card.
While I agree that this would work, it does not give the one-click
solution I would like to build. Why burden people with using dd to flash
u-boot to some magic offset on sdcard?

Maybe we can add u-boot as a dependency so it is always built when
clearfog is selected?
> 
> Also one ext4 partition for boot and second one for rootfs would be
> better than fat32 + squashfs on sdcard, both Marvell u-boot and
> uboot-mvebu have support for loading kernel from ext4.
Very interesting you would argue on this part!
So I will just outline the reasons why I made this choice:
1) fat32
make it easier to edit boot files for Windows users too.
I think this will be very useful when somebody wants to supply bootargs
or try a different kernel, but is not familiar with using unix.
2) squashfs
I like the read-only nature of squashfs. What I am working towards is a
system that feels like just any router out there. Factory wiping
involves just clearing the read-write part of storage, while firmware
updates replace the read-only parts.
If anyone messes up, they can just mkfs.ext4, or rm -rf * on the data
partition.

Please let me know if you agree or disagree here.
> 
>>PROFILES_LIST += $(1)
>>  endef
>>
>> diff --git a/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh
>> b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh
>> new file mode 100755
>> index 000..88d017a
>> --- /dev/null
>> +++ b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh
>> @@ -0,0 +1,100 @@
>> +#!/bin/bash -x
>> +#
>> +# Copyright (C) 2016 Josua Mayer
>> +#
>> +# This program is free software; you can redistribute it and/or
>> +# modify it under the terms of the GNU General Public License
>> +# as published by the Free Software Foundation; either version 2
>> +# of the License, or (at your option) any later version.
>> +#
>> +# This program is distributed in the hope that it will be useful,
>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +# GNU General Public License for more details.
>> +#
>> +# You should have received a copy of the GNU General Public License
>> +# along with this program; if not, write to the Free Software
>> +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Bo

Re: [OpenWrt-Devel] [PATCH v4 1/4] mvebu: add squashfs image type to MMCProfile

2016-05-05 Thread Andrej Vlasic

Hi Josua,

On 04.05.2016 21:24, josua.maye...@gmail.com wrote:

From: Josua Mayer 

Added gen_mvebu_sdcard_img.sh to create bootable sdcard images. It takes
the bootloader and partition images to create a bootable sdcard image.

Partition Layout:
p1: fat32: for kernel, dtb and boot config files if any
p2: squashfs: for openwrt

This change is developed for the Clearfog, but should work on all A38x
SoCs that can boot from mmc.

Signed-off-by: Josua Mayer 
---
 target/linux/mvebu/image/Makefile|  16 
 target/linux/mvebu/image/gen_mvebu_sdcard_img.sh | 100 +++
 tools/Makefile   |   1 +
 3 files changed, 117 insertions(+)
 create mode 100755 target/linux/mvebu/image/gen_mvebu_sdcard_img.sh

diff --git a/target/linux/mvebu/image/Makefile 
b/target/linux/mvebu/image/Makefile
index cb73c3b..fc5fded 100644
--- a/target/linux/mvebu/image/Makefile
+++ b/target/linux/mvebu/image/Makefile
@@ -107,6 +107,9 @@ define MMCProfile
 ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
$(call Image/Build/Profile,$(1)/Initramfs)
 endif
+ifneq ($(CONFIG_TARGET_ROOTFS_SQUASHFS),)
+   $(call Image/Build/squashfs)
+endif
   endef

   define Image/Build/Profile/$(1)/Initramfs
@@ -114,6 +117,19 @@ define MMCProfile
cp $(KDIR)/uImage-initramfs-$(2) $(BIN_DIR)/$(IMG_PREFIX)-$(2)-initramfs
   endef

+  define Image/Build/Profile/$(1)/squashfs
+   $(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
+   cp $(KDIR)/root.squashfs $(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs
+   rm -f $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32
+   mkfs.fat -C $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(shell echo 
$$((4*1024)) # 4MB)
+   mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(KDIR)/zImage ::
+   mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(DTS_DIR)/$(2).dtb ::
+   ./gen_mvebu_sdcard_img.sh 
"$(BIN_DIR)/$(IMG_PREFIX)-$(2)-squashfs-sdcard.img" \
+   
"$(BIN_DIR)/uboot-mvebu-clearfog/openwrt-mvebu-clearfog-u-boot-spl.kwb" \
+   c "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32" \
+   83 "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs"
+  endef
+


Image generation script here requires u-boot binary to exist, but what 
if one doesn't select u-boot to be generated? It would be better to 
exclude it from generated sdcard image, it can be flashed anyway with dd 
to beginning of the sd card.


Also one ext4 partition for boot and second one for rootfs would be 
better than fat32 + squashfs on sdcard, both Marvell u-boot and 
uboot-mvebu have support for loading kernel from ext4.



   PROFILES_LIST += $(1)
 endef

diff --git a/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh 
b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh
new file mode 100755
index 000..88d017a
--- /dev/null
+++ b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh
@@ -0,0 +1,100 @@
+#!/bin/bash -x
+#
+# Copyright (C) 2016 Josua Mayer
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, 
USA.
+#
+
+usage() {
+   echo "$0   [ ]?"
+}
+
+# always require first 2 arguments
+# then in pairs up to 8 more for a total of up to 4 partitions
+if [ $# -lt 2 ] || [ $# -gt 10 ] || [ $((($#-2)%2)) -ne 0 ]; then
+   usage
+   exit 1
+fi
+
+# static settings
+SDCARD_HEADS=16
+SDCARD_SECTORS=63
+SDCARD_ALIGNMENT=4096
+
+# parameters
+OUTFILE="$1"
+BOOTLOADER="$2"
+# up to 4 partitions
+# when calculating size of images in Kilobytes, NEVER round down!
+PART1_TYPE=$3
+PART1_IMG="$4"
+PART1_SIZE=$((($(stat --print="%s" "$PART1_IMG")+1023)/1024))K
+PART2_TYPE=$5
+PART2_IMG="$6"
+PART2_SIZE=$((($(stat --print="%s" "$PART2_IMG")+1023)/1024))K
+PART3_TYPE=$7
+PART3_IMG="$8"
+PART3_SIZE=$((($(stat --print="%s" "$PART3_IMG")+1023)/1024))K
+PART4_TYPE=$9
+PART4_IMG="${10}"
+PART4_SIZE=$((($(stat --print="%s" "$PART4_IMG")+1023)/1024))K
+
+# So how many partitions were given?
+numparts=$((($#-2)/2))
+case $numparts in
+   0)
+   set `ptgen -o "$OUTFILE" \
+   -h $SDCARD_HEADS -s $SDCARD_SECTORS -l 
$SDCARD_ALIGNMENT`
+   dd of="$OUTFILE" if="$BOOTLOADER" bs=512 seek=1 
conv=notrunc
+   ;;
+   1)
+   set `ptgen -o "$OUTFILE" \
+   -h $SDCARD_HEADS -s $SDCARD_SECTORS -l 
$SDCARD_ALIGNMEN

Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Hartmut Knaack
mbm schrieb am 05.05.2016 um 21:22:
> On 5/5/2016 7:40 AM, Felix Fietkau wrote:
>> Many of the changes that we previously tried to introduce were often 
>> squashed by internal disagreements. Resulting discussions often turned 
>> toxic quickly and led to nothing being done to address the issues. 
>> Setting up the LEDE project was our way of creating a testbed for 
>> changes that we believe are important for the survival of the project. 
> 
> Change is not easy. Discussions need to happen. The problem is simply 
> kicking out people you didn't agree with by starting a new organization 
> in secret; you've created the public perception that we're somehow 
> against you when really we all want the same things.
> 
>> A critical part of many of these debates was the fact that people who 
>> were controlling critical pieces of the infrastructure flat out 
>> refused to allow other people to step up and help, even in the face of 
>> being unable to deal with important issues themselves in a timely 
>> manner. This kind of single-point-of-failure thing has been going on 
>> for years, with no significant progress on resolving it. In the LEDE 
>> project we decided to significantly simplify the infrastructure and 
>> spread out admin access enough to minimize the chance of this 
>> situation ever happening again. 
>> While we have pushed for and actively worked on decentralizing the
>> infrastructure, we were also frequently asked to move back to
>> centralizing things again.
>> The excessive downtime of the main site this year is a good example of
>> why we definitely don't want to go that way.
> 
> I'll let Kaloz address this personally.
> 
>> Do you think we can get the changes outlined by the LEDE project
>> implement in OpenWrt? If so, how?
> 
> We can start by having an actual conversation between the two groups. 
> I'm not against what LEDE was trying to accomplish, but I am against how 
> it was done.
> 
>> We appreciate your effort to have an open discussion about this, 
>> however the sudden deletion of our widely published openwrt.org email 
>> addresses somewhat undermines this. We will not respond in kind and we 
>> will continue to maintain the critical parts of OpenWrt infrastructure 
>> that we control.
> 
> Let's be clear on this subject; no commit access was revoked, you still 
> have full read and write access to the entire OpenWrt tree.
> 
> Email forwarding was temporarily disabled following the LEDE announcement
> - LEDE's own rules prohibit project based email addresses
> - It's unclear if LEDE still represents OpenWrt
> 

Disabling someone's email-account without prior notice and a decent time frame
just because you don't agree with that persons behavior is totally immature
and inappropriate. The 'excuse' pointed out here just demonstrates this
ridiculousness.
Just my 2 cents.
Hartmut

> My hope is that this whole LEDE vs OpenWrt situation can be resolved.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 



0xFAC89148.asc
Description: application/pgp-keys


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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Felix Fietkau
On 2016-05-05 20:22, mbm wrote:
> On 5/5/2016 7:40 AM, Felix Fietkau wrote:
>> Many of the changes that we previously tried to introduce were often 
>> squashed by internal disagreements. Resulting discussions often turned 
>> toxic quickly and led to nothing being done to address the issues. 
>> Setting up the LEDE project was our way of creating a testbed for 
>> changes that we believe are important for the survival of the project. 
> 
> Change is not easy. Discussions need to happen. The problem is simply 
> kicking out people you didn't agree with by starting a new organization 
> in secret; you've created the public perception that we're somehow 
> against you when really we all want the same things.
Years of internal discussion led nowhere. Maybe it helps now that we're
making the whole issue public.

>> We appreciate your effort to have an open discussion about this, 
>> however the sudden deletion of our widely published openwrt.org email 
>> addresses somewhat undermines this. We will not respond in kind and we 
>> will continue to maintain the critical parts of OpenWrt infrastructure 
>> that we control.
> 
> Let's be clear on this subject; no commit access was revoked, you still 
> have full read and write access to the entire OpenWrt tree.
> 
> Email forwarding was temporarily disabled following the LEDE announcement
> - LEDE's own rules prohibit project based email addresses
No, they don't. They state that the LEDE project won't provide project
email addresses. Interpreting that as meaning that we shouldn't be able
to access our openwrt.org addresses is more than a bit of a stretch.

> - It's unclear if LEDE still represents OpenWrt
So? Asking us to not send any further emails about LEDE from our
openwrt.org addresses should have been enough.

> My hope is that this whole LEDE vs OpenWrt situation can be resolved.
I hope so too.

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Daniel Dickinson
On 16-05-05 03:22 PM, mbm wrote:
> On 5/5/2016 7:40 AM, Felix Fietkau wrote:
>> Many of the changes that we previously tried to introduce were often
>> squashed by internal disagreements. Resulting discussions often turned
>> toxic quickly and led to nothing being done to address the issues.
>> Setting up the LEDE project was our way of creating a testbed for
>> changes that we believe are important for the survival of the project. 
> 
> Change is not easy. Discussions need to happen. The problem is simply
> kicking out people you didn't agree with by starting a new organization

That depends - is 'people you don't agree with' a majority that is being
sidelined by a new organization or a minority trying dictate to the
majority?

Regards,

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


Re: [OpenWrt-Devel] [PATCH netifd] device: Don't process link events anymore in device user specific callback handlers

2016-05-05 Thread Matthias Schiffer
On 11/02/2015 11:16 AM, Hans Dedecker wrote:
> Set link_state for all device types via the device_set_link API as all 
> devices are registered
> in the device tree list making it possible to always get the device via 
> device_get.
> The decice link state parameter will now actually reflect the corresponding 
> kernel device
> carrier state in all cases.
> Before this change a vlan/macvlan device could still have link_state enabled 
> if an interface
> was brought down; this was the case when the parent vlan/macvlan device was 
> still enabled as
> the netlink link_state event would be dropped for vlan/macvlan devices due to 
> keep_link_state
> in the function cb_rtnl_event.
> 
> Signed-off-by: Hans Dedecker 
> ---

This patch breaks the following setup:

I have a WLAN device, and on top of it a VLAN device which uses a shell
proto. Example:

config interface 'test'
option proto 'static'
option ipaddr '192.168.2.1'
option netmask '255.255.255.0'

config interface 'test2'
option ifname '@test.1'
option proto 'dhcp'


where 'test' is referenced by a wifi-iface. In this setup, wlan0.1 is
created, but the DHCP client never comes up (other shell protos yield the
same result).

If I revert this patch, or change @test.1 to wlan0.1, everything works fine.

Regards,
Matthias



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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Daniel Dickinson
Might I submit that my impression is that Kaloz (at least) holds
infrastructure hostage to maintain control, and that the fundamental
problem here is that OpenWrt is *not* democratic and ignores what people
who were ones visibly working on openwrt want and overrides their wishes
because he/they has/have the keys.

That doesn't work.  Perhaps I'm wrong, but that is certainly my impression.

There isn't management for openwrt except by democratic/meritocratic
principles, and no one should try to force it to be otherwise.

Regards,

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread mbm

On 5/5/2016 7:40 AM, Felix Fietkau wrote:
Many of the changes that we previously tried to introduce were often 
squashed by internal disagreements. Resulting discussions often turned 
toxic quickly and led to nothing being done to address the issues. 
Setting up the LEDE project was our way of creating a testbed for 
changes that we believe are important for the survival of the project. 


Change is not easy. Discussions need to happen. The problem is simply 
kicking out people you didn't agree with by starting a new organization 
in secret; you've created the public perception that we're somehow 
against you when really we all want the same things.


A critical part of many of these debates was the fact that people who 
were controlling critical pieces of the infrastructure flat out 
refused to allow other people to step up and help, even in the face of 
being unable to deal with important issues themselves in a timely 
manner. This kind of single-point-of-failure thing has been going on 
for years, with no significant progress on resolving it. In the LEDE 
project we decided to significantly simplify the infrastructure and 
spread out admin access enough to minimize the chance of this 
situation ever happening again. 
While we have pushed for and actively worked on decentralizing the

infrastructure, we were also frequently asked to move back to
centralizing things again.
The excessive downtime of the main site this year is a good example of
why we definitely don't want to go that way.


I'll let Kaloz address this personally.


Do you think we can get the changes outlined by the LEDE project
implement in OpenWrt? If so, how?


We can start by having an actual conversation between the two groups. 
I'm not against what LEDE was trying to accomplish, but I am against how 
it was done.


We appreciate your effort to have an open discussion about this, 
however the sudden deletion of our widely published openwrt.org email 
addresses somewhat undermines this. We will not respond in kind and we 
will continue to maintain the critical parts of OpenWrt infrastructure 
that we control.


Let's be clear on this subject; no commit access was revoked, you still 
have full read and write access to the entire OpenWrt tree.


Email forwarding was temporarily disabled following the LEDE announcement
- LEDE's own rules prohibit project based email addresses
- It's unclear if LEDE still represents OpenWrt

My hope is that this whole LEDE vs OpenWrt situation can be resolved.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread David Lang

On Thu, 5 May 2016, Carlos Ferreira wrote:


I don't see the end of OpenWRT as a bad thing.
If LEDE is basically a fork but without the development bottlenecks that
seem to be affecting OpenwRT, then the change can be easily done by the
industry segment that uses OpenWRT for their products. In fact, I see it as
a good thing because it means that there are developers who care about the
future of such embedded development environment.


The loss of brand recognition is a bad thing (see LibreOffice vs OpenOffice for 
example)


but that said, this doesn't have to be permanent (see egcs vs gcc for example)

David Lang___
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] Introducing the LEDE project

2016-05-05 Thread Daniel Golle
Hi Daniel,

I already merged lynxis series now that I see your comment.
If you feel like it, it'd be nice if you point out the remaining
places where the name needs to be replaced and submit (a) patch(es).

Cheers

Daniel

On Thu, May 05, 2016 at 02:03:43PM -0400, Daniel Dickinson wrote:
> If you're interested, I can send you examples of a full rebrand patchset
> (there are *quite* a few places to change, and this patchset doesn't get
> them all) which I used in a "Don't blame OpenWrt" patchset I created
> when I forked (although never publicly announced as wasn't entirely
> convinced of the worth, and it wasn't ready).
> 
> Regards,
> 
> Daniel
> 
> On 16-05-05 01:33 PM, Alexander Couzens wrote:
> > Signed-off-by: Alexander Couzens 
> > ---
> >  target/imagebuilder/Config.in   | 2 +-
> >  target/imagebuilder/files/repositories.conf | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/target/imagebuilder/Config.in b/target/imagebuilder/Config.in
> > index 1bc4533..245c715 100644
> > --- a/target/imagebuilder/Config.in
> > +++ b/target/imagebuilder/Config.in
> > @@ -1,5 +1,5 @@
> >  config IB
> > -   bool "Build the OpenWrt Image Builder"
> > +   bool "Build the LEDE Image Builder"
> > depends on !PROFILE_KCONFIG
> > depends on !EXTERNAL_TOOLCHAIN
> > help
> > diff --git a/target/imagebuilder/files/repositories.conf 
> > b/target/imagebuilder/files/repositories.conf
> > index 8f1f27f..93ed97b 100644
> > --- a/target/imagebuilder/files/repositories.conf
> > +++ b/target/imagebuilder/files/repositories.conf
> > @@ -1,4 +1,4 @@
> >  ## Place your custom repositories here, they must match the architecture 
> > and version.
> >  # src/gz %n %U
> > -# src custom file:///usr/src/openwrt/bin/%T/packages
> > +# src custom file:///usr/src/lede/bin/%T/packages
> >  
> > 
> 
> ___
> 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] Introducing the LEDE project

2016-05-05 Thread Daniel Dickinson
On 16-05-05 01:49 PM, Roman Yeryomin wrote:
> On 5 May 2016 at 20:09, Daniel Dickinson  wrote:
>> On 16-05-05 12:59 PM, Roman Yeryomin wrote:
>>> On 5 May 2016 at 19:29, Daniel Dickinson  
>>> wrote:
 On 16-05-05 12:24 PM, Daniel Dickinson wrote:
> On 16-05-05 12:21 PM, Jonathan Bennett wrote:
> [snip]
>> [snip]
 When I say broken I mean I think openwrt was dying and I pointed out not
 all that long ago that openwrt was in bad position and that something
 needed to change, and I think that may have been *part* of the reason
 accepting the status quo was no longer an acceptable answer.
>>>
>>> I don't believe that those who are in LEDE now couldn't do anything
>>> (that means is was dying in their hands). Actually I'm still under
>>
>> I guess the real test will be what happens going forward - if LEDE dies
>> for the same reasons OpenWrt was dying then that puts paid to LEDE's
>> story; it it succeeds then it vindicates them.
> 
> I hope the problems will be resolved and we will have one project.

That would be ideal, but I am doubtful, unless part(y|ies) involved have
a major change of heart.

> 
>>> impression that they controlled pretty much everything. And the part
>>> they didn't control (what exactly?) was only important to them.
>>
>> I have no clue about this part, I'm not exactly in the loop.  I think
>> part of the problem has been that there is no means to add new
>> developers, and that suggestions for adding developers have been opposed
>> (that's a guess though).
> 
> I don't think it was opposed. And I don't think it was a major problem.

You sound like you know more than I about this.  It was a guess.  Only
actual information will really answer the question.

>>> But I guess we will never know full story, unless both parties are
>>> willing to disclose all their private conversations related to
>>> project.
>>
>> Yeah, pretty much we're left guessing unless there is more information
>> given.  I'm thinking the LEDE split was not like a conspiratorial split
>> where everything is carefully planned out and orchestrated, but more of
>> a rapid response (given that this isn't part of paid work for the most
>> of them, and even then the LEDE split wouldn't likely be part of the
>> job/contract) to something behind the scenes.  Even if the LEDE team is
>> unable to post to this list, I hope they give more information using the
>> avenues available to them, once they get the chance to do so.
> 
> Look at mailing list, commits and domain.
> It was all started back in March and was not disclosed. That means the
> plans were even earlier.

Based on https://lede-project.org/wp-...@wwsnet.net.mbox it was merely
an idea until early March, and again, to me indicates that things going
on in the OpenWrt project that pushed the LEDE team to the breaking
point, and which, contrary to Mike's email, were not being addressed (as
Felix pointed out in his response, which I'm not sure if was accepted on
this list, although it was in the To:).

Regards,

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Roman Yeryomin
On 5 May 2016 at 20:09, Daniel Dickinson  wrote:
> On 16-05-05 12:59 PM, Roman Yeryomin wrote:
>> On 5 May 2016 at 19:29, Daniel Dickinson  
>> wrote:
>>> On 16-05-05 12:24 PM, Daniel Dickinson wrote:
 On 16-05-05 12:21 PM, Jonathan Bennett wrote:
 [snip]
> [snip]
>>> When I say broken I mean I think openwrt was dying and I pointed out not
>>> all that long ago that openwrt was in bad position and that something
>>> needed to change, and I think that may have been *part* of the reason
>>> accepting the status quo was no longer an acceptable answer.
>>
>> I don't believe that those who are in LEDE now couldn't do anything
>> (that means is was dying in their hands). Actually I'm still under
>
> I guess the real test will be what happens going forward - if LEDE dies
> for the same reasons OpenWrt was dying then that puts paid to LEDE's
> story; it it succeeds then it vindicates them.

I hope the problems will be resolved and we will have one project.

>> impression that they controlled pretty much everything. And the part
>> they didn't control (what exactly?) was only important to them.
>
> I have no clue about this part, I'm not exactly in the loop.  I think
> part of the problem has been that there is no means to add new
> developers, and that suggestions for adding developers have been opposed
> (that's a guess though).

I don't think it was opposed. And I don't think it was a major problem.

>> But I guess we will never know full story, unless both parties are
>> willing to disclose all their private conversations related to
>> project.
>
> Yeah, pretty much we're left guessing unless there is more information
> given.  I'm thinking the LEDE split was not like a conspiratorial split
> where everything is carefully planned out and orchestrated, but more of
> a rapid response (given that this isn't part of paid work for the most
> of them, and even then the LEDE split wouldn't likely be part of the
> job/contract) to something behind the scenes.  Even if the LEDE team is
> unable to post to this list, I hope they give more information using the
> avenues available to them, once they get the chance to do so.

Look at mailing list, commits and domain.
It was all started back in March and was not disclosed. That means the
plans were even earlier.

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Daniel Dickinson
On 16-05-05 12:59 PM, Roman Yeryomin wrote:
> On 5 May 2016 at 19:29, Daniel Dickinson  wrote:
>> On 16-05-05 12:24 PM, Daniel Dickinson wrote:
>>> On 16-05-05 12:21 PM, Jonathan Bennett wrote:
>>> [snip]
[snip]
>> When I say broken I mean I think openwrt was dying and I pointed out not
>> all that long ago that openwrt was in bad position and that something
>> needed to change, and I think that may have been *part* of the reason
>> accepting the status quo was no longer an acceptable answer.
> 
> I don't believe that those who are in LEDE now couldn't do anything
> (that means is was dying in their hands). Actually I'm still under

I guess the real test will be what happens going forward - if LEDE dies
for the same reasons OpenWrt was dying then that puts paid to LEDE's
story; it it succeeds then it vindicates them.

> impression that they controlled pretty much everything. And the part
> they didn't control (what exactly?) was only important to them.

I have no clue about this part, I'm not exactly in the loop.  I think
part of the problem has been that there is no means to add new
developers, and that suggestions for adding developers have been opposed
(that's a guess though).

> But I guess we will never know full story, unless both parties are
> willing to disclose all their private conversations related to
> project.

Yeah, pretty much we're left guessing unless there is more information
given.  I'm thinking the LEDE split was not like a conspiratorial split
where everything is carefully planned out and orchestrated, but more of
a rapid response (given that this isn't part of paid work for the most
of them, and even then the LEDE split wouldn't likely be part of the
job/contract) to something behind the scenes.  Even if the LEDE team is
unable to post to this list, I hope they give more information using the
avenues available to them, once they get the chance to do so.

Regards,

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Roman Yeryomin
On 5 May 2016 at 19:29, Daniel Dickinson  wrote:
> On 16-05-05 12:24 PM, Daniel Dickinson wrote:
>> On 16-05-05 12:21 PM, Jonathan Bennett wrote:
>> [snip]
>>> > The changes that the Lede guys are suggesting would be welcome, but
>>> > splitting the project and community with an ugly fork is very much not
>>> > welcome.
>>>
>>> Let's just say that there are strong personalities who haven't been
>>> working well together and that this has been a long time coming; perhaps
>>> if something like using a mediator had been considered before things got
>>> to this point it would have helped.  At this point I'm not sure
>>> there is a
>>> solution unless both sides are willing to bend a little (I'm really not
>>> sure who has been flexible and who has not, but as I have said I suspect
>>> a large part of the issue is that 'management' (who aren't and don't,
>>> really) has overruled those doing the majority of the work and in an
>>> open source project that doesn't fly).
>>>
>>> I don't disagree.  I just see the current state of Openwrt/Lede as a
>>> mess for the community.
>>
>> I agree, I just don't see how the LEDE team could have avoided it
>> without giving up and accepting the broken status quo.
>
> When I say broken I mean I think openwrt was dying and I pointed out not
> all that long ago that openwrt was in bad position and that something
> needed to change, and I think that may have been *part* of the reason
> accepting the status quo was no longer an acceptable answer.

I don't believe that those who are in LEDE now couldn't do anything
(that means is was dying in their hands). Actually I'm still under
impression that they controlled pretty much everything. And the part
they didn't control (what exactly?) was only important to them.
But I guess we will never know full story, unless both parties are
willing to disclose all their private conversations related to
project.

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Bill
I confess I am one of those people who has benefited much more than I 
have contributed to the OpenWRT development group. I run a small company 
in which I am the chief developer, administrator, customer support dude, 
marketer, and salesguy. I would LOVE to be able to contribute more to 
the OpenWRT community, and I do try to test things that are in my way 
and report what I find from those tests, but I certainly don't feel I 
pull my weight.


However, in my defense, as you can probably surmise from the description 
of my job, we're not exactly rolling in extra money or time to 
contribute. Which I regret, but it is what it is. Anyone interested in 
joining a currently unfunded startup using OpenWRT, please get in touch.


I recently purchased a WiFi access point that I realized upon plugging 
it in was running a somewhat restricted version of OpenWRT. I won't say 
who makes it, but it's a very clever, one might say ingenious, product 
that I like very much.


However, when I looked at the OpenWRT tree, I could not find an OpenWRT 
build for this particular device. And that, I must say, has REALLY 
annoyed me - the company clearly expended some resources to port OpenWRT 
to their clever device, and certainly benefits from it, but they 
apparently did not contribute the work they did to support this device 
back to the community so it could be "officially" part of the OpenWRT 
ecosystem.


I have also been painfully aware of the infrastructure difficulties that 
OpenWRT has faced, and I have been quietly admiring the work of those 
who keep it running as well as it does. As scary as it was when IBM got 
deeply involved in Linux back in the early 2000s, for instance, I would 
say their involvement has benefited both parties.


OpenWRT is actually a pretty mature and popular codebase, and it 
deserves much better infrastructure than it has now. In order to get a 
better infrastructure, of course, we need, as a community, to attract 
partners with the ability to contribute that infrastructure. It's great 
to be in a project that is not beholden to any big companies UNTIL you 
actually want to get something significant done. Pragmatism has its place.


That's why I was a bit taken aback at the reluctance to embrace prpl's 
offer. I would like to see an organization in which all possible 
partners should be welcomed into the community; while we should be 
appropriately cautious about accepting code from anyone, and subject it 
to strict review as to suitability, fit with mission and architecture, 
and quality, we should be pulling partners in, not holding them at arm's 
length. My hope is that LEDE will either bring this level of pragmatism 
or will enable OpenWRT to be more pragmatic.


Of course, we have to be clear about the mission, architecture, and the 
standards of suitability and quality... perhaps that is the departure 
point for LEDE? I, for one, am eager to better understand, in full 
atomic granularity, the problems that have led to this departure and 
what, again, in atomic granularity, LEDE proposes to do differently.


My thinking is that, if OpenWRT or LEDE is able to attract more support 
from the corporate world, it will serve as an example to those who are 
using OpenWRT/LEDE of what is expected of a larger company that is 
gaining from the use of the software, hopefully pressuring them to step 
up and be better members of the community. I also think that it will 
lead to more visibility, which can help bring in folks like me who have 
an idea and can leverage off of OpenWRT/LEDE to produce products that 
are out of the mainstream.


I'm not privy to all, indeed, any, of the discussions that have led to 
this point of departure; I am commenting as a strict outsider. My simple 
desire is to see the codebase continue to grow, in both code and users, 
and the community to be as open and welcoming as possible. I hope that 
this move will help achieve that for at least one of the resultant 
groups. And I shall do what I can to help either or both. My last 
comment is that the more open of the two communities is likely to be the 
one where I can most easily see how I might contribute.


-Bill

--
Bill Moffitt
Ayrstone Productivity LLC

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Daniel Dickinson
On 16-05-05 12:24 PM, Daniel Dickinson wrote:
> On 16-05-05 12:21 PM, Jonathan Bennett wrote:
> [snip]
>> > The changes that the Lede guys are suggesting would be welcome, but
>> > splitting the project and community with an ugly fork is very much not
>> > welcome.
>>
>> Let's just say that there are strong personalities who haven't been
>> working well together and that this has been a long time coming; perhaps
>> if something like using a mediator had been considered before things got
>> to this point it would have helped.  At this point I'm not sure
>> there is a
>> solution unless both sides are willing to bend a little (I'm really not
>> sure who has been flexible and who has not, but as I have said I suspect
>> a large part of the issue is that 'management' (who aren't and don't,
>> really) has overruled those doing the majority of the work and in an
>> open source project that doesn't fly).
>>
>> I don't disagree.  I just see the current state of Openwrt/Lede as a
>> mess for the community.
> 
> I agree, I just don't see how the LEDE team could have avoided it
> without giving up and accepting the broken status quo.

When I say broken I mean I think openwrt was dying and I pointed out not
all that long ago that openwrt was in bad position and that something
needed to change, and I think that may have been *part* of the reason
accepting the status quo was no longer an acceptable answer.

Regards,

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Daniel Dickinson
On 16-05-05 12:21 PM, Jonathan Bennett wrote:
[snip]
> > The changes that the Lede guys are suggesting would be welcome, but
> > splitting the project and community with an ugly fork is very much not
> > welcome.
> 
> Let's just say that there are strong personalities who haven't been
> working well together and that this has been a long time coming; perhaps
> if something like using a mediator had been considered before things got
> to this point it would have helped.  At this point I'm not sure
> there is a
> solution unless both sides are willing to bend a little (I'm really not
> sure who has been flexible and who has not, but as I have said I suspect
> a large part of the issue is that 'management' (who aren't and don't,
> really) has overruled those doing the majority of the work and in an
> open source project that doesn't fly).
> 
> I don't disagree.  I just see the current state of Openwrt/Lede as a
> mess for the community.

I agree, I just don't see how the LEDE team could have avoided it
without giving up and accepting the broken status quo.

Regards,

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Jonathan Bennett
On Thu, May 5, 2016 at 10:58 AM Daniel Dickinson <
open...@daniel.thecshore.com> wrote:

> On 16-05-05 11:38 AM, Jonathan Bennett wrote:
> > There is plenty of blame to go around, I think.  Seems like the Lede
> > guys should have had the decency to at least inform the Openwrt
> > leadership privately that they were planning this venture.  The surprise
>
> The problem is that LEDE is pretty much who should be considered
> "OpenWrt Leadership" IMO as they are the majority of ones doing the
> actual work.  This isn't like working for some bad corp (I currently
> have good managers so it's better than for me even at work) where there
> are (supposed to be) execs making the decisions regardless of what those
> doing the work think.
>
> > announcement must have felt very much like a stab in the back. "Et tu,
> > brute?" and all that.  I think they want a "friendly fork" as much as
> > possible, but they dropped the ball in how they announced it.  I suspect
> > that a private email to mbm and kaloz could have gone a long ways
> > towards heading off problems.  As has been pointed out, the public
>
> I think the reason for no private email was either fear of retaliation
> or something major had already happened 'behind-the-scenes' that made
> that moot.
>
> I'm not sure their silence is entirely their choice as well (as in I
> find the lack of any posts has me wondering if they can post).
>
> > announcement should not have come from an @openwrt.org
> >  email.
>
> That much I agree with.
>
> >
> > That said, deleting their emails was totally uncalled for.  Seems that
> > those should be restored, perhaps with the caveat that they are more
> > carefully used with regards to Lede, aka, not for publicizing or
> > promoting it.
> >
> > Guys, for the love of the project, the users, and all else that is good,
> > please don't make this a ffmpeg/libav split.  Openwrt has been an
> > amazing thing for a long time, and if mishandled, this has the potential
> > to actually kill it.
> >
> > The changes that the Lede guys are suggesting would be welcome, but
> > splitting the project and community with an ugly fork is very much not
> > welcome.
>
> Let's just say that there are strong personalities who haven't been
> working well together and that this has been a long time coming; perhaps
> if something like using a mediator had been considered before things got
> to this point it would have helped.  At this point I'm not sure there is a
> solution unless both sides are willing to bend a little (I'm really not
> sure who has been flexible and who has not, but as I have said I suspect
> a large part of the issue is that 'management' (who aren't and don't,
> really) has overruled those doing the majority of the work and in an
> open source project that doesn't fly).
>
I don't disagree.  I just see the current state of Openwrt/Lede as a mess
for the community.

>
> Regards,
>
> Daniel
> ___
> 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] Introducing the LEDE project

2016-05-05 Thread Daniel Dickinson
On 16-05-05 11:38 AM, Jonathan Bennett wrote:
> There is plenty of blame to go around, I think.  Seems like the Lede
> guys should have had the decency to at least inform the Openwrt
> leadership privately that they were planning this venture.  The surprise

The problem is that LEDE is pretty much who should be considered
"OpenWrt Leadership" IMO as they are the majority of ones doing the
actual work.  This isn't like working for some bad corp (I currently
have good managers so it's better than for me even at work) where there
are (supposed to be) execs making the decisions regardless of what those
doing the work think.

> announcement must have felt very much like a stab in the back. "Et tu,
> brute?" and all that.  I think they want a "friendly fork" as much as
> possible, but they dropped the ball in how they announced it.  I suspect
> that a private email to mbm and kaloz could have gone a long ways
> towards heading off problems.  As has been pointed out, the public

I think the reason for no private email was either fear of retaliation
or something major had already happened 'behind-the-scenes' that made
that moot.

I'm not sure their silence is entirely their choice as well (as in I
find the lack of any posts has me wondering if they can post).

> announcement should not have come from an @openwrt.org
>  email.

That much I agree with.

> 
> That said, deleting their emails was totally uncalled for.  Seems that
> those should be restored, perhaps with the caveat that they are more
> carefully used with regards to Lede, aka, not for publicizing or
> promoting it.
> 
> Guys, for the love of the project, the users, and all else that is good,
> please don't make this a ffmpeg/libav split.  Openwrt has been an
> amazing thing for a long time, and if mishandled, this has the potential
> to actually kill it.
> 
> The changes that the Lede guys are suggesting would be welcome, but
> splitting the project and community with an ugly fork is very much not
> welcome.

Let's just say that there are strong personalities who haven't been
working well together and that this has been a long time coming; perhaps
if something like using a mediator had been considered before things got
to this point it would have helped.  At this point I'm not sure there is a
solution unless both sides are willing to bend a little (I'm really not
sure who has been flexible and who has not, but as I have said I suspect
a large part of the issue is that 'management' (who aren't and don't,
really) has overruled those doing the majority of the work and in an
open source project that doesn't fly).

Regards,

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Jonathan Bennett
There is plenty of blame to go around, I think.  Seems like the Lede guys
should have had the decency to at least inform the Openwrt leadership
privately that they were planning this venture.  The surprise announcement
must have felt very much like a stab in the back. "Et tu, brute?" and all
that.  I think they want a "friendly fork" as much as possible, but they
dropped the ball in how they announced it.  I suspect that a private email
to mbm and kaloz could have gone a long ways towards heading off problems.
As has been pointed out, the public announcement should not have come from
an @openwrt.org email.

That said, deleting their emails was totally uncalled for.  Seems that
those should be restored, perhaps with the caveat that they are more
carefully used with regards to Lede, aka, not for publicizing or promoting
it.

Guys, for the love of the project, the users, and all else that is good,
please don't make this a ffmpeg/libav split.  Openwrt has been an amazing
thing for a long time, and if mishandled, this has the potential to
actually kill it.

The changes that the Lede guys are suggesting would be welcome, but
splitting the project and community with an ugly fork is very much not
welcome.

--Jonathan Bennett

On Thu, May 5, 2016 at 10:12 AM John Clark  wrote:

>  >>the sudden deletion of our widely published openwrt.org email
> addresses somewhat undermines this
>
> Just so I am not jumping to wrong conclusions, their *.openwrt.org email
> addresses were deleted in retaliation for forking OpenWrt? Seriously?
> How did you not think that wasn't going to go well after all they have
> done for OpenWrt?
>
> --John
>
>
> On 5/5/16 11:04 AM, Roman Yeryomin wrote:
> > On 5 May 2016 at 17:43, Daniel Dickinson 
> wrote:
> >> On 16-05-05 05:34 AM, Roman Yeryomin wrote:
> >>> On 5 May 2016 at 06:48, Daniel Dickinson 
> wrote:
>  On 16-05-04 04:01 PM, mbm wrote:
> > Dear OpenWrt community,
> >
> >> [snip]
> >>> One simple question:
> >>> If LEDE team members are the ones who were suffering from some
> >>> non-democratic decisions, why didn't they bring it to public
> >>> discussion for community? At least on devel maillist?
> >>>
> >>> If it was clear problem in remaining OpenWrt team then LEDE would win
> >>> the community right away or maybe problematic people would just go
> >>> away. Either way it would be more fair and open. And this is one of my
> >>> biggest concerns - LEDE team is promoting openness but didn't do their
> >>> moves openly (looking at maillists it seems they were hiding it for
> >>> month at least). Hate double standards.
> >> Perhaps for fear of repercussions such as what has happened since the
> >> fork where all LEDE members @openwrt.org email addresses have been
> deleted?
> > AFAIK, that was done after LEDE announcement but IMO was a wrong move
> anyway.
> >
> >> There are a number of people in the LEDE group I've found to be pretty
> >> decent people, and great to work with, so I find it unlikely that they
> >> simply acted without good reason.
> > This only add more shock to the announcement.
> >
> > Regards,
> > Roman
> > ___
> > 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] Introducing the LEDE project

2016-05-05 Thread Daniel Petre



On 05/05/2016 06:38 PM, Jonathan Bennett wrote:

There is plenty of blame to go around, I think.  Seems like the Lede
guys should have had the decency to at least inform the Openwrt
leadership privately that they were planning this venture.


If i read correctly the feedback from the LEDE guys (and many of the 
people in here) then it seems EVEN THEY did not had any serious real 
feedback since a while ago from the main OpenWrt "headquarters".


So.. what do you do when you ask (probably several times) and do not get 
any answer at all.. ?

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Daniel Dickinson
On 16-05-05 11:24 AM, Daniel Dickinson wrote:
> On 16-05-05 11:11 AM, John Clark wrote:
 the sudden deletion of our widely published openwrt.org email
>> addresses somewhat undermines this
>>
>> Just so I am not jumping to wrong conclusions, their *.openwrt.org email
> 
> @openwrt.org actually
> 
>> addresses were deleted in retaliation for forking OpenWrt? Seriously? 
> 
> Yep.
> 
>> How did you not think that wasn't going to go well after all they have
>> done for OpenWrt?
> 
> I think you mean "How did you think that wasn't *not* going to go well
> after all they have done for OpenWrt".
> 

Sorry, my bad, I parsed you wrong, you had the right grammer.

Regards,

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Daniel Dickinson
On 16-05-05 11:11 AM, John Clark wrote:
>>>the sudden deletion of our widely published openwrt.org email
> addresses somewhat undermines this
> 
> Just so I am not jumping to wrong conclusions, their *.openwrt.org email

@openwrt.org actually

> addresses were deleted in retaliation for forking OpenWrt? Seriously? 

Yep.

> How did you not think that wasn't going to go well after all they have
> done for OpenWrt?

I think you mean "How did you think that wasn't *not* going to go well
after all they have done for OpenWrt".

Regards,

Daniel

> 
> --John
> 
> 
> On 5/5/16 11:04 AM, Roman Yeryomin wrote:
>> On 5 May 2016 at 17:43, Daniel Dickinson
>>  wrote:
>>> On 16-05-05 05:34 AM, Roman Yeryomin wrote:
 On 5 May 2016 at 06:48, Daniel Dickinson
  wrote:
> On 16-05-04 04:01 PM, mbm wrote:
>> Dear OpenWrt community,
>>
>>> [snip]
 One simple question:
 If LEDE team members are the ones who were suffering from some
 non-democratic decisions, why didn't they bring it to public
 discussion for community? At least on devel maillist?

 If it was clear problem in remaining OpenWrt team then LEDE would win
 the community right away or maybe problematic people would just go
 away. Either way it would be more fair and open. And this is one of my
 biggest concerns - LEDE team is promoting openness but didn't do their
 moves openly (looking at maillists it seems they were hiding it for
 month at least). Hate double standards.
>>> Perhaps for fear of repercussions such as what has happened since the
>>> fork where all LEDE members @openwrt.org email addresses have been
>>> deleted?
>> AFAIK, that was done after LEDE announcement but IMO was a wrong move
>> anyway.
>>
>>> There are a number of people in the LEDE group I've found to be pretty
>>> decent people, and great to work with, so I find it unlikely that they
>>> simply acted without good reason.
>> This only add more shock to the announcement.
>>
>> Regards,
>> Roman
>> ___
>> 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] Introducing the LEDE project

2016-05-05 Thread John Clark
>>the sudden deletion of our widely published openwrt.org email 
addresses somewhat undermines this


Just so I am not jumping to wrong conclusions, their *.openwrt.org email 
addresses were deleted in retaliation for forking OpenWrt? Seriously?  
How did you not think that wasn't going to go well after all they have 
done for OpenWrt?


--John


On 5/5/16 11:04 AM, Roman Yeryomin wrote:

On 5 May 2016 at 17:43, Daniel Dickinson  wrote:

On 16-05-05 05:34 AM, Roman Yeryomin wrote:

On 5 May 2016 at 06:48, Daniel Dickinson  wrote:

On 16-05-04 04:01 PM, mbm wrote:

Dear OpenWrt community,


[snip]

One simple question:
If LEDE team members are the ones who were suffering from some
non-democratic decisions, why didn't they bring it to public
discussion for community? At least on devel maillist?

If it was clear problem in remaining OpenWrt team then LEDE would win
the community right away or maybe problematic people would just go
away. Either way it would be more fair and open. And this is one of my
biggest concerns - LEDE team is promoting openness but didn't do their
moves openly (looking at maillists it seems they were hiding it for
month at least). Hate double standards.

Perhaps for fear of repercussions such as what has happened since the
fork where all LEDE members @openwrt.org email addresses have been deleted?

AFAIK, that was done after LEDE announcement but IMO was a wrong move anyway.


There are a number of people in the LEDE group I've found to be pretty
decent people, and great to work with, so I find it unlikely that they
simply acted without good reason.

This only add more shock to the announcement.

Regards,
Roman
___
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] Introducing the LEDE project

2016-05-05 Thread Roman Yeryomin
On 5 May 2016 at 17:43, Daniel Dickinson  wrote:
> On 16-05-05 05:34 AM, Roman Yeryomin wrote:
>> On 5 May 2016 at 06:48, Daniel Dickinson  
>> wrote:
>>> On 16-05-04 04:01 PM, mbm wrote:
 Dear OpenWrt community,

> [snip]
>>
>> One simple question:
>> If LEDE team members are the ones who were suffering from some
>> non-democratic decisions, why didn't they bring it to public
>> discussion for community? At least on devel maillist?
>>
>> If it was clear problem in remaining OpenWrt team then LEDE would win
>> the community right away or maybe problematic people would just go
>> away. Either way it would be more fair and open. And this is one of my
>> biggest concerns - LEDE team is promoting openness but didn't do their
>> moves openly (looking at maillists it seems they were hiding it for
>> month at least). Hate double standards.
>
> Perhaps for fear of repercussions such as what has happened since the
> fork where all LEDE members @openwrt.org email addresses have been deleted?

AFAIK, that was done after LEDE announcement but IMO was a wrong move anyway.

> There are a number of people in the LEDE group I've found to be pretty
> decent people, and great to work with, so I find it unlikely that they
> simply acted without good reason.

This only add more shock to the announcement.

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Daniel Dickinson
On 16-05-05 05:34 AM, Roman Yeryomin wrote:
> On 5 May 2016 at 06:48, Daniel Dickinson  wrote:
>> On 16-05-04 04:01 PM, mbm wrote:
>>> Dear OpenWrt community,
>>>
[snip]
> 
> One simple question:
> If LEDE team members are the ones who were suffering from some
> non-democratic decisions, why didn't they bring it to public
> discussion for community? At least on devel maillist?
> 
> If it was clear problem in remaining OpenWrt team then LEDE would win
> the community right away or maybe problematic people would just go
> away. Either way it would be more fair and open. And this is one of my
> biggest concerns - LEDE team is promoting openness but didn't do their
> moves openly (looking at maillists it seems they were hiding it for
> month at least). Hate double standards.

Perhaps for fear of repercussions such as what has happened since the
fork where all LEDE members @openwrt.org email addresses have been deleted?

There are a number of people in the LEDE group I've found to be pretty
decent people, and great to work with, so I find it unlikely that they
simply acted without good reason.

Regards,

Daniel

> 
> 
>>> We do acknowledge there has been internal disagreements, on several
>>> occasions about some directions of the project, about the release model,
>>> the lack of testing, the centralized infrastructure, however, there have
>>> been actual work going on under the hoods to solve things one step at a
>>
>> Perhaps 'under-the-hood' is the problem.  Did everyone with concerns
>> know or have insight into what steps were currently being taken and what
>> was planned, and have planned actions been followed through on, once
>> *agreed* as a solution?
>>
>> Also, is the decision making process egalitarian and democratic amongst
>> those still actively in the project, or are some 'more equal' than others?
>>
>> Regards,
>>
>> Daniel
>> ___
>> 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] Introducing the LEDE project

2016-05-05 Thread Felix Fietkau
Hi Mike,

thank you for reaching out to us and for your interest in addressing
these issues.

On 2016-05-04 21:01, mbm wrote:
> Dear OpenWrt community,
> 
> It is with a great amount of surprise that, like all of you, we read 
> about the announcement of the LEDE project yesterday, as there was no 
> prior announcement nor clues this would happen.
> 
> While we recognize the current OpenWrt project suffers from a number of 
> issues outlined by Jo-Philip, in each of the 5 bullet points, we do not 
> agree with the conclusions withdrawn, and even less so in deciding to 
> spin off the OpenWrt project in the first place as a way to fix the 
> project and its community. Also, the phrases such as a "reboot" are both 
> vague and misleading and the LEDE project failed to identify its true 
> nature. The LEDE announcement  contains a number of very valid points 
> which we hoped we had an opportunity to discuss and attempt to fix, in a 
> public manner, before this more radical outcome. At this point, the 
> email as well as actions taken are very confusing to a lot of us.
Many of the changes that we previously tried to introduce were often
squashed by internal disagreements. Resulting discussions often turned
toxic quickly and led to nothing being done to address the issues.
Setting up the LEDE project was our way of creating a testbed for
changes that we believe are important for the survival of the project.

> OpenWrt is primarily developed by individuals who may have a day job 
> more or less related to the purpose or the technologies of the project, 
> but who strive to maintain OpenWrt as independent as possible  from any 
> company, organization or interest group, thus maintaining its own 
> infrastructure (website, forums, mailing-lists, bugtracker...), which 
> has been usually at the heart of all debates.
A critical part of many of these debates was the fact that people who
were controlling critical pieces of the infrastructure flat out refused
to allow other people to step up and help, even in the face of being
unable to deal with important issues themselves in a timely manner.

This kind of single-point-of-failure thing has been going on for years,
with no significant progress on resolving it.

In the LEDE project we decided to significantly simplify the
infrastructure and spread out admin access enough to minimize the chance
of this situation ever happening again.

> We do acknowledge there has been internal disagreements, on several 
> occasions about some directions of the project, about the release model, 
> the lack of testing, the centralized infrastructure, however, there have 
> been actual work going on under the hoods to solve things one step at a 
> time, starting with a more decentralized infrastructure, which was 
> discussed with the LEDE developers as well.
While we have pushed for and actively worked on decentralizing the
infrastructure, we were also frequently asked to move back to
centralizing things again.
The excessive downtime of the main site this year is a good example of
why we definitely don't want to go that way.

> At this point, we do not have much to offer to the LEDE developers but 
> to encourage them to publicly discuss on
> openwrt-devel@lists.openwrt.org the different items we should all be 
> fixing together, and avoid spinning off so that all decisions can be 
> taken with the community's involvement, and accountability and 
> transparency can rule us as one community.
Do you think we can get the changes outlined by the LEDE project
implement in OpenWrt? If so, how?

> As a user, developer, contributor, or just community member, whatever 
> choice you make, keep the choice that matters to you: the ability to 
> utilize superior quality open source software to power whatever embedded 
> device that matters to you!
> 
> We would like to stress that we do want to have an open discussion and 
> resolve matters at hand. Our goal is to work with all parties who can 
> and want to contribute to OpenWrt, including the LEDE team.
We appreciate your effort to have an open discussion about this, however
the sudden deletion of our widely published openwrt.org email addresses
somewhat undermines this.
We will not respond in kind and we will continue to maintain the
critical parts of OpenWrt infrastructure that we control.

Regards,

Felix Fietkau
Jo-Philipp Wich
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Aaron Z
On Thu, May 5, 2016 at 9:06 AM, Bruno Randolf  wrote:
>
> But as someone who is following, using, building upon and sometimes
> contributing to OpenWRT since ~10 years I can only say that the only
> developers who have been visible, reacting and committing stuff have
> left. I still wonder why, of course...
+1 (although I might change "the only" to "the majority of the").

Aaron Z
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects.
— Robert Heinlein, Time Enough for Love
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Bruno Randolf
On 05/05/16 13:48, Zoltan HERPAI wrote:
> I would not call "all active OpenWrt core developers" have left the
> boat. Take a look at this [1] page - some of them are active, some of
> them are not, but calling an end to the project is an overstatement at
> least. Also, refer to the mail Mike sent out last night.

Well, you are right, I should not make predictions of the future... ;)

But as someone who is following, using, building upon and sometimes
contributing to OpenWRT since ~10 years I can only say that the only
developers who have been visible, reacting and committing stuff have
left. I still wonder why, of course...

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


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Zoltan HERPAI

Hi,

On Thu, 5 May 2016, Bruno Randolf wrote:


On 05/05/16 02:02, Kathy Giori wrote:

On Wed, May 4, 2016 at 5:45 PM, Fernando Frediani  wrote:

Thanks Daniel. That explains a lot.
I imagine if some digging is done it would be possible to find the holders
of the critical resources and then re-organize it from scratch within the
OpenWrt Project.
But as the fork has already happened there is no much point in doing that.


My conclusion is: As all active OpenWRT core developers have left the
boat there must be something going on behind the scenes, which they feel
can not be fixed within OpenWRT. If they don't change their mind, that's
probably the end of OpenWRT, then...


I would not call "all active OpenWrt core developers" have left the boat. 
Take a look at this [1] page - some of them are active, some of them are 
not, but calling an end to the project is an overstatement at least. 
Also, refer to the mail Mike sent out last night.


Thanks,
-w-

[1] https://dev.openwrt.org/wiki/people
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] brcm63xx: add Observa VH4032N support

2016-05-05 Thread dani
Add support for the Observa VH4032N router.

It's a BCM6368 based board with 128MB RAM, 32MB flash.
Equiped with an onboard USB hub. This hub has the RST#
pin wired to the GPIO27 pin. For pulling the chip out of reset,
we use ephy_reset since there isn't specific code for this
function in the USB driver.

The board has also switch LEDs, but they don't work as it 
happens with other bcm6368 boards. The GPIO pinmux
still needs to be fixed for these hw controlled switch LEDs.

Signed-off-by: Daniel Gonzalez 
diff -urN ./target/linux/brcm63xx/profiles/observa.mk 
./target/linux/brcm63xx/profiles/observa.mk
--- ./target/linux/brcm63xx/profiles/observa.mk 1970-01-01 01:00:00.0 
+0100
+++ ./target/linux/brcm63xx/profiles/observa.mk 2016-04-20 21:13:56.680702590 
+0200
@@ -0,0 +1,9 @@
+define Profile/VH4032N
+  NAME:=Observa Telecom VH4032N 
+  PACKAGES:=kmod-b43 kmod-usb-core kmod-usb-ohci kmod-usb2 wpad-mini
+endef
+define Profile/VH4032N/Description
+   Package set for the Observa Telecom VH4032N
+endef
+$(eval $(call Profile,VH4032N))
+
diff -urN ./target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc 
./target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
--- ./target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc  
2016-04-20 14:23:53.371339556 +0200
+++ ./target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc  
2016-04-20 19:41:14.853717064 +0200
@@ -30,6 +30,7 @@
spw303v |\
v2110 |\
v2500v_bb |\
+   vh4032n |\
vr-3025u |\
vr-3025un |\
vr-3026e |\
diff -urN ./target/linux/brcm63xx/base-files/etc/board.d/02_network 
./target/linux/brcm63xx/base-files/etc/board.d/02_network
--- ./target/linux/brcm63xx/base-files/etc/board.d/02_network   2016-04-20 
14:23:53.371339556 +0200
+++ ./target/linux/brcm63xx/base-files/etc/board.d/02_network   2016-04-20 
19:41:14.853717064 +0200
@@ -90,6 +90,7 @@
 hg655b |\
 p870hw-51a_v2 |\
 r5010un_v2 |\
+vh4032n |\
 vr-3025un |\
 vr-3025u |\
 vr-3026e)
diff -urN ./target/linux/brcm63xx/base-files/etc/diag.sh 
./target/linux/brcm63xx/base-files/etc/diag.sh
--- ./target/linux/brcm63xx/base-files/etc/diag.sh  2016-04-20 
14:23:53.371339556 +0200
+++ ./target/linux/brcm63xx/base-files/etc/diag.sh  2016-04-20 
19:30:24.628933412 +0200
@@ -30,6 +30,9 @@
bcm96348gw-11)
status_led="96348GW-11:green:power"
;;
+   vh4032n)
+   status_led="VH4032N:red:power"
+   ;;
spw303v)
status_led="spw303v:green:power+adsl"
;;
diff -urN ./target/linux/brcm63xx/base-files/lib/brcm63xx.sh 
./target/linux/brcm63xx/base-files/lib/brcm63xx.sh
--- ./target/linux/brcm63xx/base-files/lib/brcm63xx.sh  2016-04-20 
14:23:53.371339556 +0200
+++ ./target/linux/brcm63xx/base-files/lib/brcm63xx.sh  2016-04-20 
20:53:21.196234734 +0200
@@ -186,6 +186,9 @@
"NuCom R5010UN v2")
board_name="r5010un_v2"
;;
+   "Observa VH4032N")
+   board_name="vh4032n"
+   ;;
"Pirelli A226G")
board_name="a226g"
;;
diff -urN ./target/linux/brcm63xx/dts/vh4032n.dts 
./target/linux/brcm63xx/dts/vh4032n.dts
--- ./target/linux/brcm63xx/dts/vh4032n.dts 1970-01-01 01:00:00.0 
+0100
+++ ./target/linux/brcm63xx/dts/vh4032n.dts 2016-04-20 20:21:35.905231536 
+0200
@@ -0,0 +1,89 @@
+/dts-v1/;
+
+#include "bcm6368.dtsi"
+
+#include 
+
+/ {
+   model = "Observa VH4032N";
+   compatible = "observa,vh4032n", "brcm,bcm6368";
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <20>;
+   debounce-interval = <60>;
+
+   reset {
+   label = "reset";
+   gpios = <&gpio1 2 1>;
+   linux,code = ;
+   };
+   wps {
+   label = "wps";
+   gpios = <&gpio1 3 1>;
+   linux,code = ;
+   };
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   dsl_blue {
+   label = "VH4032N:blue:dsl";
+   gpios = <&gpio0 2 1>;
+   };
+   dsl_red {
+   label = "VH4032N:red:dsl";
+   gpios = <&gpio0 5 1>;
+   };
+   hspa_blue {
+   label = "VH4032N:blue:hspa";
+   gpios = <&gpio0 11 1>;
+   };
+   hspa_red {
+   label = "VH4032N:red:hspa";
+   gpios = <&gpio0 12 1>;
+   };
+   power_blue {
+   label = "VH4032N:blue:power";
+   gpios = <&gpio0 22 0>;
+   };
+   power_red {
+

Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Carlos Ferreira
I don't see the end of OpenWRT as a bad thing.
If LEDE is basically a fork but without the development bottlenecks that
seem to be affecting OpenwRT, then the change can be easily done by the
industry segment that uses OpenWRT for their products. In fact, I see it as
a good thing because it means that there are developers who care about the
future of such embedded development environment.

On 5 May 2016 at 12:32, Bruno Randolf  wrote:

> On 05/05/16 02:02, Kathy Giori wrote:
> > On Wed, May 4, 2016 at 5:45 PM, Fernando Frediani 
> wrote:
> >> Thanks Daniel. That explains a lot.
> >> I imagine if some digging is done it would be possible to find the
> holders
> >> of the critical resources and then re-organize it from scratch within
> the
> >> OpenWrt Project.
> >> But as the fork has already happened there is no much point in doing
> that.
>
> My conclusion is: As all active OpenWRT core developers have left the
> boat there must be something going on behind the scenes, which they feel
> can not be fixed within OpenWRT. If they don't change their mind, that's
> probably the end of OpenWRT, then...
>
> bruno
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>



-- 

Carlos Miguel Ferreira
Researcher at Telecommunications Institute
Aveiro - Portugal
Work E-mail - c...@av.it.pt
Skype & GTalk -> carlosmf...@gmail.com
LinkedIn -> http://www.linkedin.com/in/carlosmferreira
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Bruno Randolf
On 05/05/16 02:02, Kathy Giori wrote:
> On Wed, May 4, 2016 at 5:45 PM, Fernando Frediani  
> wrote:
>> Thanks Daniel. That explains a lot.
>> I imagine if some digging is done it would be possible to find the holders
>> of the critical resources and then re-organize it from scratch within the
>> OpenWrt Project.
>> But as the fork has already happened there is no much point in doing that.

My conclusion is: As all active OpenWRT core developers have left the
boat there must be something going on behind the scenes, which they feel
can not be fixed within OpenWRT. If they don't change their mind, that's
probably the end of OpenWRT, then...

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


[OpenWrt-Devel] [PATCH] ar71xx: add Mikrotik's yaffs2 file system support.

2016-05-05 Thread adron
From: Sergey Sergeev 

This patch adds support of Mikrotik yaffs2 filesystem image for kernel file
and tools/kernel2minor package.
We neede this to boot kernel through RouterBoot on new Mikrotik NOR flash 
devices.

Signed-off-by: Sergey Sergeev 
---
 config/Config-images.in| 31 ++
 scripts/metadata.pl|  1 +
 target/Config.in   |  3 +++
 target/linux/ar71xx/image/Makefile | 14 ++
 target/linux/ar71xx/mikrotik/target.mk |  4 ++--
 tools/Makefile |  1 +
 tools/kernel2minor/Makefile| 35 ++
 7 files changed, 87 insertions(+), 2 deletions(-)
 create mode 100644 tools/kernel2minor/Makefile

diff --git a/config/Config-images.in b/config/Config-images.in
index a60dd50..c7d1898 100644
--- a/config/Config-images.in
+++ b/config/Config-images.in
@@ -6,6 +6,37 @@
 
 menu "Target Images"
 
+   menuconfig TARGET_KERNELFS_MIKROTIK_YAFFS2
+   bool "kernel2mikrotikyaffs2"
+   default y if USES_KERNEL2MIKROTIKYAFFS2
+   depends on USES_KERNEL2MIKROTIKYAFFS2
+   help
+ Build a Mikrotik's version of Yaffs2 filesystem which 
contains only a single kernel file.
+ This is necessary for boot through RouterBoot boot loader.
+
+   config TARGET_MIKROTIK_YAFFS2_NOR_FLASH_IMG
+   bool "NOR flash image"
+   depends on TARGET_KERNELFS_MIKROTIK_YAFFS2
+   default "y"
+   help
+ Build Mikrotik's Yaffs2 filesystem image for NOR 
flash boards:
+   Mikrotik rb941-2nd(hAP lite)
+   And maby(not tested yet) all new routerboards with 
this strings in description:
+   Storage typeFLASH
+   Storage size16 MB
+
+   config TARGET_MIKROTIK_YAFFS2_NAND_2048B_ECC_FLASH_IMG
+   bool "NAND flash (2048b with ECC) image"
+   depends on TARGET_KERNELFS_MIKROTIK_YAFFS2
+   default "y"
+   help
+ Build Mikrotik's Yaffs2 filesystem image for NAND 
flash boards:
+   Mikrotik rb750 and rb751
+   And maby(not tested yet) all routerboards with NAND 
flash parameters like this:
+   Eraseblock size:131072 bytes, 
128.0 KiB
+   Minimum input/output unit size: 2048 bytes
+   OOB size:   64 bytes
+
menuconfig TARGET_ROOTFS_INITRAMFS
bool "ramdisk"
default y if USES_INITRAMFS
diff --git a/scripts/metadata.pl b/scripts/metadata.pl
index 99fdba1..17c3176 100755
--- a/scripts/metadata.pl
+++ b/scripts/metadata.pl
@@ -134,6 +134,7 @@ sub target_config_features(@) {
/ext4/ and $ret .= "\tselect USES_EXT4\n";
/targz/ and $ret .= "\tselect USES_TARGZ\n";
/cpiogz/ and $ret .= "\tselect USES_CPIOGZ\n";
+   /kernel2mikrotikyaffs2/ and $ret .= "\tselect 
USES_KERNEL2MIKROTIKYAFFS2\n";
/ubifs/ and $ret .= "\tselect USES_UBIFS\n";
/fpu/ and $ret .= "\tselect HAS_FPU\n";
/spe_fpu/ and $ret .= "\tselect HAS_SPE_FPU\n";
diff --git a/target/Config.in b/target/Config.in
index 571b06e..b9e10bd 100644
--- a/target/Config.in
+++ b/target/Config.in
@@ -63,6 +63,9 @@ config USES_TARGZ
 config USES_CPIOGZ
bool
 
+config USES_KERNEL2MIKROTIKYAFFS2
+   bool
+
 config USES_UBIFS
bool
select NAND_SUPPORT
diff --git a/target/linux/ar71xx/image/Makefile 
b/target/linux/ar71xx/image/Makefile
index bc8a4a8..9419c5f 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -1492,6 +1492,17 @@ define MkuImageOKLI
 endef
 endif
 
+define kernel2mikrotikyaffs2
+#NOR flash
+ifneq ($(CONFIG_TARGET_MIKROTIK_YAFFS2_NOR_FLASH_IMG),)
+   $(STAGING_DIR_HOST)/bin/kernel2minor -k $(KDIR)/loader-generic.elf -r 
$(VMLINUX)-lzma.nor-tik-yaffs2 -s 1024 -e
+endif
+#NAND flash 2048b with ECC
+ifneq ($(CONFIG_TARGET_MIKROTIK_YAFFS2_NAND_2048B_ECC_FLASH_IMG),)
+   $(STAGING_DIR_HOST)/bin/kernel2minor -k $(KDIR)/loader-generic.elf -r 
$(VMLINUX)-lzma.nand-tik-yaffs2-2048b-ecc -s 2048 -c -e
+endif
+endef
+
 # $(1): name of the 1st file.
 # $(2): size limit of the 1st file if it is greater than 262144, or
 #   the erase size of the flash if it is greater than zero and less
@@ -1682,6 +1693,9 @@ define Image/BuildKernel
$(call MkuImage,gzip,,$(KDIR)/vmlinux.bin.gz,$(UIMAGE)-gzip.bin)
$(call MkuImage,lzma,,$(KDIR)/vmlinux.bin.lzma,$(UIMAGE)-lzma.bin)
cp $(KDIR)/loader-generic.elf $(VMLINUX)-lzma.elf
+ifneq ($(CONFIG_TARGET_KERNELFS_MI

[OpenWrt-Devel] [PATCH] ramips: Introduce serial0 aliases for active console in dts

2016-05-05 Thread Stanislav Galabov
This patch introduces serial0 aliases in the ramips DTS files, which can then 
be used to denote the active console instead of relying on bootargs.

Signed-off-by: Stanislav Galabov 

—

diff --git a/target/linux/ramips/dts/LINKIT7688.dts 
b/target/linux/ramips/dts/LINKIT7688.dts
index 2dfb98c..bb38c88 100644
--- a/target/linux/ramips/dts/LINKIT7688.dts
+++ b/target/linux/ramips/dts/LINKIT7688.dts
@@ -10,6 +10,10 @@
bootargs = "console=ttyS2,57600";
};

+   aliases {
+   serial0 = &uart2;
+   };
+
memory@0 {
device_type = "memory";
reg = <0x0 0x800>;
diff --git a/target/linux/ramips/dts/mt7620a.dtsi 
b/target/linux/ramips/dts/mt7620a.dtsi
index 5edbdf9..3c89880 100644
--- a/target/linux/ramips/dts/mt7620a.dtsi
+++ b/target/linux/ramips/dts/mt7620a.dtsi
@@ -23,6 +23,7 @@
aliases {
spi0 = &spi0;
spi1 = &spi1;
+   serial0 = &uartlite;
};

palmbus@1000 {
@@ -239,7 +240,7 @@
pinctrl-0 = <&spi_cs1>;
};

-   uartlite@c00 {
+   uartlite: uartlite@c00 {
compatible = "ralink,mt7620a-uart", 
"ralink,rt2880-uart", "ns16550a";
reg = <0xc00 0x100>;

diff --git a/target/linux/ramips/dts/mt7620n.dtsi 
b/target/linux/ramips/dts/mt7620n.dtsi
index e8ce3b2..7e66abe 100644
--- a/target/linux/ramips/dts/mt7620n.dtsi
+++ b/target/linux/ramips/dts/mt7620n.dtsi
@@ -23,6 +23,7 @@
aliases {
spi0 = &spi0;
spi1 = &spi1;
+   serial0 = &uartlite;
};

palmbus@1000 {
@@ -191,7 +192,7 @@
pinctrl-0 = <&spi_cs1>;
};

-   uartlite@c00 {
+   uartlite: uartlite@c00 {
compatible = "ralink,mt7620a-uart", 
"ralink,rt2880-uart", "ns16550a";
reg = <0xc00 0x100>;

diff --git a/target/linux/ramips/dts/mt7621.dtsi 
b/target/linux/ramips/dts/mt7621.dtsi
index 24e0459..94cff26 100644
--- a/target/linux/ramips/dts/mt7621.dtsi
+++ b/target/linux/ramips/dts/mt7621.dtsi
@@ -5,6 +5,10 @@
#size-cells = <1>;
compatible = "mediatek,mtk7621-soc";

+   aliases {
+   serial0 = &uartlite;
+   };
+
cpus {
cpu@0 {
compatible = "mips,mips1004Kc";
@@ -100,7 +104,7 @@
reg = <0x1fbf8000 0x8000>;
};

-   uartlite@c00 {
+   uartlite: uartlite@c00 {
compatible = "ns16550a";
reg = <0xc00 0x100>;

diff --git a/target/linux/ramips/dts/mt7628an.dtsi 
b/target/linux/ramips/dts/mt7628an.dtsi
index e120e56..c1f03fc 100644
--- a/target/linux/ramips/dts/mt7628an.dtsi
+++ b/target/linux/ramips/dts/mt7628an.dtsi
@@ -13,6 +13,10 @@
bootargs = "console=ttyS0,57600";
};

+   aliases {
+   serial0 = &uartlite;
+   };
+
cpuintc: cpuintc@0 {
#address-cells = <0>;
#interrupt-cells = <1>;
@@ -154,7 +158,7 @@
status = "disabled";
};

-   uartlite@c00 {
+   uartlite: uartlite@c00 {
compatible = "ns16550a";
reg = <0xc00 0x100>;

@@ -192,7 +196,7 @@
status = "disabled";
};

-   uart2@e00 {
+   uart2: uart2@e00 {
compatible = "ns16550a";
reg = <0xe00 0x100>;

diff --git a/target/linux/ramips/dts/rt2880.dtsi 
b/target/linux/ramips/dts/rt2880.dtsi
index 47ea4c3..dc3f0ba 100644
--- a/target/linux/ramips/dts/rt2880.dtsi
+++ b/target/linux/ramips/dts/rt2880.dtsi
@@ -13,6 +13,10 @@
bootargs = "console=ttyS0,57600";
};

+   aliases {
+   serial0 = &uartlite;
+   };
+
cpuintc: cpuintc@0 {
#address-cells = <0>;
#interrupt-cells = <1>;
@@ -110,7 +114,7 @@
status = "disabled";
};

-   uartlite@c00 {
+   uartlite: uartlite@c00 {
compatible = "ralink,rt2880-uart", "ns16550a";
reg = <0xc00 0x100>;

diff --git a/target/linux/ramips/dts/rt3050.dtsi 
b/target/linux/ramips/dts/rt3050.dtsi
index 8fcdeed..0a4cf1e 100644
--- a/target/linux/ramips/dts/rt3050.dtsi
+++ b/target/linux/ramips/dts/rt3050.dtsi
@@ -15,6 +15,7 @@

aliases {
spi0 = &spi0;
+   serial0 = &uartlite;
};

cpuintc: cpuintc@0 {
@@ -164,7 +165,7 @@
status = "disabled";
};

-   uartlite@c00 {
+   uartlite: uartlite@c00 {
compatible = "ralink,rt3050-uart", 
"ralink,rt2880-uart", 

Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread Roman Yeryomin
On 5 May 2016 at 13:16, John Clark  wrote:
>>Could you elaborate more and explain how exactly LEDE is going to fix
> the listed problems? And why it's not possible to fix them inside
> existing project?
>
> The hasty reasons given and the secret and abrupt severing of ties make me
> wonder if a "follow the money" approach will yield more plausible answers to
> the questions being raised.

maybe a good point, how do you "follow the money"?

> On Thu, May 5, 2016 at 5:34 AM, Roman Yeryomin 
> wrote:
>>
>> On 5 May 2016 at 06:48, Daniel Dickinson 
>> wrote:
>> > On 16-05-04 04:01 PM, mbm wrote:
>> >> Dear OpenWrt community,
>> >>
>> >> spin off the OpenWrt project in the first place as a way to fix the
>> >> project and its community. Also, the phrases such as a "reboot" are
>> >> both
>> >> vague and misleading and the LEDE project failed to identify its true
>> >> nature. The LEDE announcement  contains a number of very valid points
>> >
>> > Can you be more specific about what you believe is LEDE's 'true nature'?
>> >
>> >> which we hoped we had an opportunity to discuss and attempt to fix, in
>> >> a
>> >> public manner, before this more radical outcome. At this point, the
>> >> email as well as actions taken are very confusing to a lot of us.
>> >
>> > This is a guess: perhaps it is connected to the fact that Felix's
>> > n...@openwrt.org address now bounces, and that actions were taken which
>> > were deemed to be over-the-top by the LEDE team?  Certainly there is a
>> > great deal more doing on that either side is saying in public (which
>> > might be just as well since there seems to be a fair amount of bad
>> > feelings on both sides).
>>
>> One simple question:
>> If LEDE team members are the ones who were suffering from some
>> non-democratic decisions, why didn't they bring it to public
>> discussion for community? At least on devel maillist?
>>
>> If it was clear problem in remaining OpenWrt team then LEDE would win
>> the community right away or maybe problematic people would just go
>> away. Either way it would be more fair and open. And this is one of my
>> biggest concerns - LEDE team is promoting openness but didn't do their
>> moves openly (looking at maillists it seems they were hiding it for
>> month at least). Hate double standards.
>>
>>
>> >> We do acknowledge there has been internal disagreements, on several
>> >> occasions about some directions of the project, about the release
>> >> model,
>> >> the lack of testing, the centralized infrastructure, however, there
>> >> have
>> >> been actual work going on under the hoods to solve things one step at a
>> >
>> > Perhaps 'under-the-hood' is the problem.  Did everyone with concerns
>> > know or have insight into what steps were currently being taken and what
>> > was planned, and have planned actions been followed through on, once
>> > *agreed* as a solution?
>> >
>> > Also, is the decision making process egalitarian and democratic amongst
>> > those still actively in the project, or are some 'more equal' than
>> > others?
>> >
>> > Regards,
>> >
>> > Daniel
>> > ___
>> > 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
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-05 Thread John Clark
>Could you elaborate more and explain how exactly LEDE is going to fix
the listed problems? And why it's not possible to fix them inside
existing project?

The hasty reasons given and the secret and abrupt severing of ties make me
wonder if a "follow the money" approach will yield more plausible answers
to the questions being raised.


On Thu, May 5, 2016 at 5:34 AM, Roman Yeryomin 
wrote:

> On 5 May 2016 at 06:48, Daniel Dickinson 
> wrote:
> > On 16-05-04 04:01 PM, mbm wrote:
> >> Dear OpenWrt community,
> >>
> >> spin off the OpenWrt project in the first place as a way to fix the
> >> project and its community. Also, the phrases such as a "reboot" are both
> >> vague and misleading and the LEDE project failed to identify its true
> >> nature. The LEDE announcement  contains a number of very valid points
> >
> > Can you be more specific about what you believe is LEDE's 'true nature'?
> >
> >> which we hoped we had an opportunity to discuss and attempt to fix, in a
> >> public manner, before this more radical outcome. At this point, the
> >> email as well as actions taken are very confusing to a lot of us.
> >
> > This is a guess: perhaps it is connected to the fact that Felix's
> > n...@openwrt.org address now bounces, and that actions were taken which
> > were deemed to be over-the-top by the LEDE team?  Certainly there is a
> > great deal more doing on that either side is saying in public (which
> > might be just as well since there seems to be a fair amount of bad
> > feelings on both sides).
>
> One simple question:
> If LEDE team members are the ones who were suffering from some
> non-democratic decisions, why didn't they bring it to public
> discussion for community? At least on devel maillist?
>
> If it was clear problem in remaining OpenWrt team then LEDE would win
> the community right away or maybe problematic people would just go
> away. Either way it would be more fair and open. And this is one of my
> biggest concerns - LEDE team is promoting openness but didn't do their
> moves openly (looking at maillists it seems they were hiding it for
> month at least). Hate double standards.
>
>
> >> We do acknowledge there has been internal disagreements, on several
> >> occasions about some directions of the project, about the release model,
> >> the lack of testing, the centralized infrastructure, however, there have
> >> been actual work going on under the hoods to solve things one step at a
> >
> > Perhaps 'under-the-hood' is the problem.  Did everyone with concerns
> > know or have insight into what steps were currently being taken and what
> > was planned, and have planned actions been followed through on, once
> > *agreed* as a solution?
> >
> > Also, is the decision making process egalitarian and democratic amongst
> > those still actively in the project, or are some 'more equal' than
> others?
> >
> > Regards,
> >
> > Daniel
> > ___
> > 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] Introducing the LEDE project

2016-05-05 Thread Roman Yeryomin
On 5 May 2016 at 06:48, Daniel Dickinson  wrote:
> On 16-05-04 04:01 PM, mbm wrote:
>> Dear OpenWrt community,
>>
>> spin off the OpenWrt project in the first place as a way to fix the
>> project and its community. Also, the phrases such as a "reboot" are both
>> vague and misleading and the LEDE project failed to identify its true
>> nature. The LEDE announcement  contains a number of very valid points
>
> Can you be more specific about what you believe is LEDE's 'true nature'?
>
>> which we hoped we had an opportunity to discuss and attempt to fix, in a
>> public manner, before this more radical outcome. At this point, the
>> email as well as actions taken are very confusing to a lot of us.
>
> This is a guess: perhaps it is connected to the fact that Felix's
> n...@openwrt.org address now bounces, and that actions were taken which
> were deemed to be over-the-top by the LEDE team?  Certainly there is a
> great deal more doing on that either side is saying in public (which
> might be just as well since there seems to be a fair amount of bad
> feelings on both sides).

One simple question:
If LEDE team members are the ones who were suffering from some
non-democratic decisions, why didn't they bring it to public
discussion for community? At least on devel maillist?

If it was clear problem in remaining OpenWrt team then LEDE would win
the community right away or maybe problematic people would just go
away. Either way it would be more fair and open. And this is one of my
biggest concerns - LEDE team is promoting openness but didn't do their
moves openly (looking at maillists it seems they were hiding it for
month at least). Hate double standards.


>> We do acknowledge there has been internal disagreements, on several
>> occasions about some directions of the project, about the release model,
>> the lack of testing, the centralized infrastructure, however, there have
>> been actual work going on under the hoods to solve things one step at a
>
> Perhaps 'under-the-hood' is the problem.  Did everyone with concerns
> know or have insight into what steps were currently being taken and what
> was planned, and have planned actions been followed through on, once
> *agreed* as a solution?
>
> Also, is the decision making process egalitarian and democratic amongst
> those still actively in the project, or are some 'more equal' than others?
>
> Regards,
>
> Daniel
> ___
> 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] [PATCH] [generic] Checksum for all files inside package

2016-05-05 Thread Michal Hrusecky
This patch introduces possibility to have checksums of all files installed from
packages calculated on build and be part of the package metadata. It could be
useful to verify everything installed properly and that there are no errors on
the storage.

Signed-off-by: Michal Hrusecky 
---
 config/Config-build.in  |   9 +++
 include/package-ipkg.mk |   5 ++
 package/base-files/Makefile |   3 +
 package/base-files/files/sbin/pkg_check | 130 
 4 files changed, 147 insertions(+)
 create mode 100755 package/base-files/files/sbin/pkg_check

diff --git a/config/Config-build.in b/config/Config-build.in
index 5ad940b..dd94fc5 100644
--- a/config/Config-build.in
+++ b/config/Config-build.in
@@ -55,6 +55,15 @@ menu "Global build settings"
  This removes all ipkg/opkg status data files from the target 
directory
  before building the root filesystem.
 
+   config FILES_MD5_SUM
+   bool
+   prompt "Provide checksums for all installed files"
+   default n
+   help
+ Enables computation of md5 checksums for all files that are 
part of
+ package. Can be used to verify that filesystem is intact and 
all
+ files were correctly installed.
+
config COLLECT_KERNEL_DEBUG
bool
prompt "Collect kernel debug information"
diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk
index eb4c874..b3a0d6f 100644
--- a/include/package-ipkg.mk
+++ b/include/package-ipkg.mk
@@ -187,6 +187,11 @@ $(_endef)
$(CheckDependencies)
 
$(RSTRIP) $$(IDIR_$(1))
+   if [ "$$(CONFIG_FILES_MD5_SUM)" = "y" ]; then \
+   (cd $$(IDIR_$(1)); \
+   find . -type f \! -path ./CONTROL/\* -exec md5sum \{\} 
\; | \
+   sed 's|\([[:blank:]]\)\./|\1/|' > 
$$(IDIR_$(1))/CONTROL/files-md5sum ) \
+   fi
(cd $$(IDIR_$(1))/CONTROL; \
( \
echo "CONTROL"; \
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 8bb6225..7e0e96f 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -180,6 +180,9 @@ define Package/base-files/install
echo "{conffile##$(1)}" >> 
$(1)/CONTROL/conffiles; \
fi \
done
+ifneq ($(CONFIG_FILES_MD5_SUM),y)
+   rm $(1)/sbin/pkg_check
+endif
 endef
 
 ifneq ($(DUMP),1)
diff --git a/package/base-files/files/sbin/pkg_check 
b/package/base-files/files/sbin/pkg_check
new file mode 100755
index 000..5dadb3f
--- /dev/null
+++ b/package/base-files/files/sbin/pkg_check
@@ -0,0 +1,130 @@
+#!/bin/sh
+#
+# Package checksums checking script
+# (C) 2016 CZ.NIC, z.s.p.o.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+
+ERRFATAL="no"
+QUIET="yes"
+MISSING=""
+SUMMARY=""
+NL="
+"
+
+# Arguments parsing
+while expr "x$1" : "x-" > /dev/null; do
+   if [ "x$1" = "x-s" ]; then
+   ERRFATAL="yes"
+   shift
+   elif [ "x$1" = "x-v" ]; then
+   QUIET=" no"
+   shift
+   else
+   echo "Usage: $(basename $0) [-s] [-v] [pkg1 pkg2 ...]"
+   echo
+   echo "   -s   Stop on first change"
+   echo "   -v   Verbose"
+   if [ "x$1" = "x-h" ]; then
+   exit 0
+   else
+   echo
+   echo "ERROR: Unknown option '$1'"
+   exit 1
+   fi
+   fi
+done
+
+# Check all packages by default
+if [ -z "$1" ]; then
+   set $(cd /usr/lib/opkg/info/; for i in *.files-md5sum; do basename $i 
.files-md5sum; done)
+fi
+
+# Iterate over packages
+while [ "$1" ]; do
+   if [ \! -f "/usr/lib/opkg/info/$1.files-md5sum" ]; then
+   if [ "$ERRFATAL" = no ]; then
+   echo " * No checksums for $1 - skipping"
+   echo
+   else
+   echo " * No checksums for $1 - exiting"
+   exit 1
+   fi
+   if [ -z "$MISSING" ]; then
+   MISSING="$1"
+   else
+   MISSING="$MISSING, $1"
+   fi
+   shift
+