Re: Future of Chaos Calmer

[David Lang]

On Fri, 6 May 2016, Vittorio G (VittGam) wrote:



On 05/05/2016 21:30:56 CEST, David Lang wrote:

On Thu, 5 May 2016, Vittorio G (VittGam) wrote:


Hello,

I'd like to know if there are any plans for Chaos Calmer?

Will it become mantained by LEDE?


almost certinly not. But LEDE will create their own release to replace it.


Okay, it would be great to have a LEDE release derived by the CC codebase, 
too.


remember that part of maintaining a release is making updates to it 
available.


OpenWRT updates against *openwrt.org servers, so LEDE is not going to be 
able to do anything there.


David Lang


Trunk introduces important changes, for example the switch from uClibc to
musl, so until everything's polished and ready for release I'd rather not
use trunk on "production" devices, like the main home modem/router or all
the antennas of a wireless community that are mounted on the roofs...


shrug, you need to do testing anyway. I ran 120 APs from Trunk at the Scale 
conference in January and they worked well.


Well, of course I would never flash deployed antennas with trunk without
testing; but sometimes trunk reserves strange surprises that may not be
caught even while testing... As an extreme example, some years ago I had
some APs flashed with a supposedly "stable" revision of AA (when it still
was the trunk). After some time, when trying to update to BB, I saw that
some of the routers were rebooting in the middle of flashing, because the
watchdog process wasn't terminated properly, so the hardware watchdog
remained active and triggered in the middle of the upgrade.


True, but I've run into problems with releases having subtle problems that don't 
show up in testing too.


you pick something and take your chances :-)

and you have a plan for when, not if, something fails on you.

David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: Future of Chaos Calmer

[Vittorio G (VittGam)]

On 05/05/2016 21:30:56 CEST, David Lang wrote:

On Thu, 5 May 2016, Vittorio G (VittGam) wrote:


Hello,

I'd like to know if there are any plans for Chaos Calmer?

Will it become mantained by LEDE?


almost certinly not. But LEDE will create their own release to replace it.


Okay, it would be great to have a LEDE release derived by the CC codebase, too.


remember that part of maintaining a release is making updates to it available.

OpenWRT updates against *openwrt.org servers, so LEDE is not going to be able 
to do anything there.

David Lang


Trunk introduces important changes, for example the switch from uClibc to
musl, so until everything's polished and ready for release I'd rather not
use trunk on "production" devices, like the main home modem/router or all
the antennas of a wireless community that are mounted on the roofs...


shrug, you need to do testing anyway. I ran 120 APs from Trunk at the Scale 
conference in January and they worked well.


Well, of course I would never flash deployed antennas with trunk without
testing; but sometimes trunk reserves strange surprises that may not be
caught even while testing... As an extreme example, some years ago I had
some APs flashed with a supposedly "stable" revision of AA (when it still
was the trunk). After some time, when trying to update to BB, I saw that
some of the routers were rebooting in the middle of flashing, because the
watchdog process wasn't terminated properly, so the hardware watchdog
remained active and triggered in the middle of the upgrade.

Cheers,
Vittorio

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: project goals

[Hauke Mehrtens]

On 05/05/2016 10:03 PM, Bert Vermeulen wrote:
> On 05/05/2016 04:09 PM, Hauke Mehrtens wrote:
>> I think we should encourage everyone to upstream the patches, I think in
>> one of the statics I saw that OpenWrt ranked 3. or 4. in contribution to
>> the kernel among the Linux distributions before Canonical. ;-)
> 
> Encourage is just a word. Nobody in OpenWrt ever discouraged
> upstreaming, I should think. But without a "no non-upstreamable patches"
> policy, you will inevitably build up a technical debt.
> 
> I had a look at the OpenWrt repo over the last two years. Here's what
> the lack of such a policy did for openWrt:
> 
> - versioned kernel patches: between 1426 and 2807
> - versioned kernel patches, top kernel only: 1204 -> 977
> - non-versioned kernel patches: 177 -> 316
> - non-kernel package patches: 381 -> 514
> - tools patches: 95 -> 114
> - toolchain: 142 -> 79 (halved two weeks ago)

How did you measure these values? When you look at kernel patches it
probably only makes sense to look at the most recent kernel version
supported to not count the same patch double only because it is applied
to different kernel versions. Also this contains some backports for more
recent versions like the musl support for gcc was added in gcc and we
wanted to use it before.

> The conclusion is equally obvious and terrible: this is not going to
> resolve itself.
> 
> The number of patches being upstreamed from OpenWrt to the mainline
> kernel is in NO WAY making a dent in the patches carried along in this
> repo. Making things considerably worse is the fact that many patches are
> in no shape to be accepted by mainline -- using outdated or non-existent
> APIs, or just of shoddy quality. Upstreaming such things often means
> rewriting them completely, as I've had the misfortune to notice.

This also depends on the developer. When you look at the Broadcom
brcm47xx and bcm53xx target for example most of the mainline kernel code
was done by OpenWrt developers and first added to OpenWrt and then
upstreamed.

> Think about that for a minute: stale internal API, shoddy code, stuck in
> internal repo because used in shipping product. That is the definition
> of technical debt.
> 
> How can you possible defend this status quo?
> 
> 
>> Only allowing upstream patches also conflicts with the goal to be more
>> stable and not always use the most recent kernel which introduces new
>> problems again.
>>
>> Some kernel patches are also directly extracted from some other
>> repositories or from some vendors. The raspberry pi patches for example
>> are exported from some other repository.
> 
> Those are both very poor excuses. This project does not use the most
> recent mainline kernel because it has a thousand patches that need
> porting, not because it "introduces new problems". The problem is right
> here, nowhere else.

Makeing a target compile and boot with a more recent kernel is normally
not a big problem, but there are then some new bugs introduced by the
new kernel version and that causes some problems.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

How can I help?

[John Clark]

I have been following the OpenWrt list for a while now and have been 
active with OpenWrt for my own internal use since 2013.  I have wanted 
to become publicly active with open source embedded Linux for a while 
but have not been able to figure out how to do so.


I initially thought this OpenWrt fork was a bad thing due to the way it 
was announced and the initial lack of information.  I can now see that 
you all did the right thing and believe this will help push embedded 
Linux in the right direction.  I also have a great deal of professional 
respect for you all.


I figure you all can use a hand right now, how can I help?  This may be 
a question you all will be getting a lot of over the next few weeks.


John Clark
Raligh-Durham, NC


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: Introducing the LEDE project

[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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [RFC] A change to the way packages are built

[Michal Hrusecky]

David Lang - 10:41  5.05.16 wrote:
> On Thu, 5 May 2016, Michal Hrusecky wrote:
> 
> > David Lang - 18:20  4.05.16 wrote:
> > > Debian has ...
> > 
> > Just for the sake of discussion and inspiration, how openSUSE does it's 
> > rolling
> > release. We have OBS, which is server software, connected to multiple 
> > builders.
> > It has projects and in those projects packages. Packages can have sources
> > somewhere in the git and git hook can trigger rebuild. Builds are done in 
> > new
> > cleanly installed environment (there is option to have some precached) 
> > which is
> > afterward thrown away. When package is built, all packages in the project 
> > that
> > depends on it are rebuild, unless there is no change to the package - it is
> > binary same as the last one (somebody fixed coding style?).
> > 
> > When package is send to Tumbleweed (rolling distro) it has to first build in
> > the project it is submitted from, then it is put into staging project where 
> > it
> > is built against clean Tumbleweed and packages depending on it from 
> > Tumbleweed
> > are rebuild.  Once done, staging project is run through automatic test and 
> > if
> > it passes, it is merged.
> > 
> > One more side note, OBS is opensource, it can build packages for multiple
> > architectures and distributions (openSUSE, SUSE, RHEL, Debian, ...) and they
> > accept patches to support more distributions :-)
> 
> can it do cross-compiles?

Should be able to, we used to use it at some point, but don't know any details.
In openSUSE we first switched to qemu-user builds (to avoid all the troubles
with cross-compilation) and later on to native workers (to speed up things).
But OpenWRT/LEDE can do it on it's own and I wouldn't suggest throwing out
current build system.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [RFC] A change to the way packages are built

[Daniel Dickinson]

On 16-05-05 01:57 PM, Jo-Philipp Wich wrote:
> Hi Daniel,
> 
>> Basically one builds a minimal SDK and does kind of like Debian where a
>> git commit to a package kicks of a build of pristine environment which
>> builds only the package and it's dependencies.
> 
> I've set up a two-phase buildbot infrastructure which first builds the
> SDK for each target/subtarget, and then utilizes suitable SDKs for
> processing the package feeds, see
> 
> http://phase1.builds.lede-project.org/
> and
> http://phase2.builds.lede-project.org/

Would you be interested in looking at my patch for building a minimal
SDK?  I won't claim it's ready for LEDE use, but if you find it helpful
as starting point, I'm happy.

> This approach is far from perfect but imho a good step into the right
> direction and it would fulfill your requirement of decoupled core/feed
> builds.

Awesome.  This is definitely a big job and doing it small steps is
advisable anyway.

> 
> Once more build resources become available it becomes feasible to
> compile single packages plus their dependency trees as they're pushed.
> 
> You can find the buildbot configuration files here:
> https://git.lede-project.org/?p=buildbot.git
>

Thanks!

I might set up an experimental buildbot to try some of my ideas (also
looking at various existing tools others have pointed out).

Regards,

Daniel


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Web forums for LEDE

[David Lang]

Given that many people strongly prefer web forums, I assume that LEDE is going 
to set them up at some point.


I would like to get a request in early that the web forms that get setup be 
cross-connected with mailing lists. Not just for 'something new has happened' 
the way the OpenWRT forms are, but as true lists where someone can reply via 
e-mail and it will appear in the forum.


Baen publishing does this (bar.baen.com) allowing full participation with 
e-mail, nttp, and web forums. They use mailman for the e-mail and nntp and then 
FUDForum for the web forums (it ties in to the nntp feed that mailman can 
provide).


I believe that I saw that a recent version of mailman added a web interface to 
mailing lists, but I haven't seen anyone using it yet.


David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[PATCH 3/3] toolchain: rename OpenWrt into Lede

[Alexander Couzens]

Signed-off-by: Alexander Couzens 
---
 target/toolchain/Config.in  | 6 +++---
 target/toolchain/files/README.TOOLCHAIN | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/target/toolchain/Config.in b/target/toolchain/Config.in
index 5a6ecef..e377c20 100644
--- a/target/toolchain/Config.in
+++ b/target/toolchain/Config.in
@@ -1,8 +1,8 @@
 config MAKE_TOOLCHAIN
-   bool "Package the OpenWrt-based Toolchain"
+   bool "Package the LEDE-based Toolchain"
depends on !EXTERNAL_TOOLCHAIN
help
  Package the created toolchain as a tarball under the bin/ directory as
- 
OpenWrt-Toolchain-$(BOARD)-for-$(ARCH)$(ARCH_SUFFIX)-gcc-$(GCCV)$(DIR_SUFFIX).
+ 
LEDE-Toolchain-$(BOARD)-for-$(ARCH)$(ARCH_SUFFIX)-gcc-$(GCCV)$(DIR_SUFFIX).
  For example, a toolchain for the MIPS architecture might be named
- 
OpenWrt-Toolchain-malta-for-mipsel_mips32-gcc-4.8-linaro_uClibc-0.9.33.2.tar.bz2.
+ 
LEDE-Toolchain-malta-for-mipsel_mips32-gcc-4.8-linaro_uClibc-0.9.33.2.tar.bz2.
diff --git a/target/toolchain/files/README.TOOLCHAIN 
b/target/toolchain/files/README.TOOLCHAIN
index 40bfccc..86b0189 100644
--- a/target/toolchain/files/README.TOOLCHAIN
+++ b/target/toolchain/files/README.TOOLCHAIN
@@ -1,2 +1,2 @@
-This is the OpenWrt SDK. It contains just the toolchain created 
+This is the LEDE SDK. It contains just the toolchain created
 by buildroot.
-- 
2.8.2


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] List Prefix

[David Woodhouse]

On Thu, 2016-05-05 at 14:12 -0300, Fernando Frediani wrote:
> Come on. It´s not a big thing and it helps some people to organize
> their mailboxes in the way they prefer.
> We are talking about just 10 extra characters !

You are right. It isn't a big thing. It's just 10 extra characters.

But some of us spend our entire lives sitting in front of an email
client, scanning mailing lists for discussions that are relevant to us
— and on which we can help.

Those 10 extra characters detract from our ability to pick out the
subjects we should pay attention to. And there are *standard* places in
which the same information already exists, instead of abusing the
subject line.

There have been many cases where a thread has had to be brought
explicitly to my attention (by Cc'ing it to me), because I just haven't
*noticed* it otherwise. That happens with and without the subject
prefix, but it happens *more* on lists with a subject prefix.

Again, just personal anecdotal data. But again, it's a down-side that
it's fairly hard for recipients to *avoid* (it's distinctly non-trivial 
to remove even the one list-noise, let alone when it's cross-posted and
gains others), while it's relatively *easy* for those who want it to
actually do things properly or *even* to just add the noise for
themselves at their side. If that's *really* the user-interface that
they want.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: Introducing the LEDE project

[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-de...@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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Suggestion: apply for the Linux Foundation CII program

[Konstantin Ryabitsev]

Hello:

It sounds like this project would be a good candidate for CII support
(see https://www.coreinfrastructure.org/grants). The state of security
on consumer-grade wireless routers is overall very poor, and I believe
you will have no trouble getting CII to offer support in getting some
additional resources for the project (this is not a promise -- I am
speaking for myself, not for the CII project nor for the Linux
Foundation).

We can also offer to host the project wiki at lede.wiki.kernel.org using
Dokuwiki (e.g. see https://wireless.wiki.kernel.org). If you would like
to request it, please follow the instructions here:
https://korg.wiki.kernel.org/userdoc/wiki.

Once you have a couple of releases, please email ftpad...@kernel.org and
we will be happy to mirror the downloads for you.

Best,
-- 
Konstantin Ryabitsev
Linux Foundation Collab Projects
Montréal, Québec


signature.asc
Description: PGP signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: project goals

[Hauke Mehrtens]

On 05/04/2016 11:49 PM, Vittorio G (VittGam) wrote:
> Hi,
> 
> On 04/05/2016 22:30:40 CEST, Bert Vermeulen wrote:
>> Hi all,
>>
>> Very happy to see this project reboot happening. An acknowledgement of
>> the issues facing OpenWRT was long overdue. I'd like some clarity on
>> some things that aren't explicitly mentioned in the stated goals,
>> however.
>>
>> First off, is the SVN nonsense definitely gone now? Will the LEDE
>> project be all-git? I assume yes, but would really like to see this
>> confirmed.

LEDE does not use svn.

>> Secondly, the major technical problem OpenWRT faces IMHO has always
>> been the ever-increasing technical debt. In this case this is carried
>> in the form of a *gigantic* number of patches. There are patches for
>> lots of packages, and even the kernel and U-boot. I count over 4700 of
>> them in OpenWRT, 3842 in LEDE right now.
>>
>> This is the sort of thing you expect to see in the internal repo of a
>> company not yet convinced of the benefits of upstreaming; to see this
>> carried in an open source project is downright shocking.

They are probably worse. ;-)

>> I propose to make it an official goal to carry no patches at all;
>> everything should be upstreamed or dropped. That is the only policy
>> that makes any sense at all.
>>
>> Comments, opinions?
> 
> I personally don't think "upstream or drop" would be a good thing to do.
> 
> Regarding package patches, I think that some are just specific to make
> the package work in an embedded system, and maybe upstream can possibly
> just not be interested in this sometimes.
> 
> Regarding U-Boot patches I don't think it's not OpenWrt's fault. For
> example, many Atheros devices use an ancient trunk of U-Boot (1.1.4)
> with many patches from Atheros or router vendors applied to it. Upstream
> might simply not be interested in these patches.
> 
> Regarding kernel patches instead, the OpenWrt trunk is/was usually used
> also as a test-bed for some changes that will eventually go upstream at
> some point, and many actually went in the mainline kernel.
> 
> Upstreaming kernel patches is usually a long process, and is usually
> meant for finished and polished things, at least to some extent. So you
> can't really experiment with things anymore once it's upstreamed. You
> want to make sure that every rough edge is solved before upstreaming
> something.
> 
> Also, upstreaming patches requires some effort/time, and maybe that was
> not always present in OpenWrt, I don't know.
> 
> By the way I'm not saying either that trunk is or should be the far-west
> of wild patches... ;)
> 
> So, yes, when something is stable enough, and upstream is interested or
> otherwise upstreaming is feasible, then it should be upstreamed. But I
> believe this is already what was happening with OpenWrt...
> 
> But, no, when something still needs to be fully tested I think it should
> not be upstreamed yet, and that the OpenWrt/LEDE trunk might just the
> right place for it.

I think we should encourage everyone to upstream the patches, I think in
one of the statics I saw that OpenWrt ranked 3. or 4. in contribution to
the kernel among the Linux distributions before Canonical. ;-)

Only allowing upstream patches also conflicts with the goal to be more
stable and not always use the most recent kernel which introduces new
problems again.

Some kernel patches are also directly extracted from some other
repositories or from some vendors. The raspberry pi patches for example
are exported from some other repository.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: getting users involved in on-device testing

[Alexander Couzens]

> It kinda makes sense, although it would be even nicer if the tests
> were automated as well. That is something that Purple is working on.
> There is a BoardFarm[1] test framework that is designed to test
> routers and there could be created test suites that reflects some of
> the criteria you described and in the best case, whenever image is
> produced, automatic test could be triggered and results uploaded. It
> outputs junit and there is plenty of parsers of junit - we have it
> nicely integrated in Jenkins.
> 
> [1] https://github.com/qca/boardfarm

There is also lava [1] - built and active developed by linaro
you can use it to do `git bisect` on hardware [2]

I'll add some boards to a local instance next week. There are also nice
videos about setting your own test setup and a lot of documentation.

best,
lynxis

[1] https://validation.linaro.org/scheduler/
[2] http://lunarius.fe80.eu/blog/coreboot-bisect-lava.html
-- 
Alexander Couzens

mail: lyn...@fe80.eu
jabber: lyn...@fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604


pgp88oD9MPzQu.pgp
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[PATCH] ramips: introduce serial0 aliases for active console in dts

[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 
---
 target/linux/ramips/dts/LINKIT7688.dts | 4 
 target/linux/ramips/dts/mt7620a.dtsi   | 3 ++-
 target/linux/ramips/dts/mt7620n.dtsi   | 3 ++-
 target/linux/ramips/dts/mt7621.dtsi| 6 +-
 target/linux/ramips/dts/mt7628an.dtsi  | 8 ++--
 target/linux/ramips/dts/rt2880.dtsi| 6 +-
 target/linux/ramips/dts/rt3050.dtsi| 3 ++-
 target/linux/ramips/dts/rt3352.dtsi| 3 ++-
 target/linux/ramips/dts/rt3883.dtsi| 3 ++-
 target/linux/ramips/dts/rt5350.dtsi| 3 ++-
 10 files changed, 32 insertions(+), 10 deletions(-)

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 = 
+   };
+
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 = 
spi1 = 
+   serial0 = 
};

palmbus@1000 {
@@ -239,7 +240,7 @@
pinctrl-0 = <_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 = 
spi1 = 
+   serial0 = 
};

palmbus@1000 {
@@ -191,7 +192,7 @@
pinctrl-0 = <_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..c055285 100644
--- a/target/linux/ramips/dts/mt7621.dtsi
+++ b/target/linux/ramips/dts/mt7621.dtsi
@@ -22,6 +22,10 @@
compatible = "mti,cpu-interrupt-controller";
};

+   aliases {
+   serial0 = 
+   };
+
cpuclock: cpuclock@0 {
#clock-cells = <0>;
compatible = "fixed-clock";
@@ -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 = 
+   };
+
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 = 
+   };
+
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

Re: Contacting Felix

[Felix Fietkau]

On 2016-05-05 04:54, Daniel Dickinson wrote:
> Hey,
> 
> Could you let Felix know I wanted to apologize to him for getting upset
> previously on the openwrt list, because of situations he is obviously
> also frustrated with?
> 
> I can't reach him because n...@openwrt.org bounces and I don't have a
> record of his other addresses.
Yeah, unfortunately OpenWrt reacted to the LEDE announcement by silently
deleting openwrt.org email addresses of all LEDE members.
I hope that can be resolved somehow.

You can reach me on my primary address, n...@nbd.name.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: getting users involved in on-device testing

[Hauke Mehrtens]

On 05/05/2016 08:56 AM, John Crispin wrote:
> Hi,
> 
> It would be nice if there was a process in place that would allow
> community members to easily be able to test images on devices and report
> the results some place. after some time thinking of different ways to do
> this I came up with one possible solution and wanted to know what others
> think about this.
> 
> we setup a file similar to how the MAINTAINERS file in the kernel.
> anyone can add his name/email and boards he would like to be a tester
> of. every time an image is built for said board, an email is generated
> and sent out to the according persons. this email would contains an otp.
> with this credential you could then log into some web frontend and get a
> simple mask along the lines of
> 
> * wifi worked
> * ethernet worked
> * leds worked
> * buttons worked
> * iperf
> * ssl benchmark
> ...
> 
> this could all be done in a rather trivial manner and i dont think the
> work behind such a setup is really that huge. using otps would for
> example eliminate the need for user credential management. results could
> simply be stored in files on the backend and then harvested later by a
> secondary script etc etc...
> 
> next it would be possible to generate static content based on aggregated
> data that will show a traffic light style support status for various
> boards, listing when it was last tested, with what revision and what the
> test results were.
> 
> would something like this make sense ?
> 
>   John

I would like such a system. This could also help people to decide which
device to buy.

I think we should add a free text comment section for some special
remarks that do not fit into the yes/no/not available questions, we
should then later extend the yes/no/na questions to reflect stuff that
is often added to the comments.

We could also try to integrate this with some automated testing.

I think it would be nice to have this as an open source software and
then extend this according to our needs.

Is there anybody interested in developing such a system and releasing it
under an open source license so it can later easily be extended?

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] List Prefix

[David Woodhouse]

On Thu, 2016-05-05 at 01:37 -0700, David Lang wrote:
> 
> > can this be turned on by subscribers manually for their subscription or
> > is there only one global option ? for the list ?
> 
> I'm pretty sure it's a list-wide option.

Indeed. There are plenty of things that individual subscribers can do,
based on the existing ways of distinguishing list traffic — but Mailman
is mostly designed to deliver the *same* message to multiple
subscribers, so doesn't really offer that as a per-user option on the
list server side.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: List subject prefix?

[David Woodhouse]

On Thu, 2016-05-05 at 10:23 +0300, Hannu Nyman wrote:
> On 5.5.2016 9:59, David Woodhouse wrote:
> > It's the Mailman default, but it is deliberately disabled on this list
> > (as on many other technical lists where the members are expected to be
> > able to drive their email client properly).
> 
> That sounds pretty funny on 2010s when most of us use multiple devices to 
> read mail. The list prefix makes it easier to quickly identify the general 
> nature of a message on tablet/phone screen

Each of us has different use cases, of course. But for me, having it in
a different folder is even easier — since most of the time when I'm not
at a real computer, I don't even want to *see* the list traffic — and
when I'm out of the country, I *certainly* don't want to pay roaming
data rates for downloading it!

It can go into one of the dozens of mailing list folders. On the *rare* 
occasion that I actually do want to look at list traffic from a mobile device, 
it's hardly difficult to switch to that folder (after I make sure I find wifi).

> Sure, we all can tinker with the desktop mail client classification rules, 
> but not all mobile apps are that well adjustable. A short list prefix would 
> make life more easy.

Yeah, filtering on the *client* side only ever made sense in the POP3
days — where you had only one mail client, on only one machine. You
really do want the *server* to put it in the right place on delivery,
not mess around with it afterwards.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] List Prefix

[David Lang]

On Thu, 5 May 2016, John Crispin wrote:


On 05/05/2016 10:14, David Woodhouse wrote:

On Thu, 2016-05-05 at 08:13 +0200, John Crispin wrote:


Hi David,

some folks would prefer to have the prefix on the 2 lists. I just had a
look in the mailman settings and failed to quickly spot the location
where this can be achieved.


Ick, they really ought to be able to handle that locally without
polluting the subject header for everyone. But if you want to turn it
back on, it's in the 'general options' page — the first one when you
log in to the admin interface. About the fourth option down.

Or directly at
http://lists.infradead.org/mailman/admin/lede-adm/?VARHELP=general/subject_prefix



can this be turned on by subscribers manually for their subscription or
is there only one global option ? for the list ?


I'm pretty sure it's a list-wide option.

David Lang___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [RFC] A change to the way packages are built

[Michal Hrusecky]

David Lang - 18:20  4.05.16 wrote:
> Debian has ...

Just for the sake of discussion and inspiration, how openSUSE does it's rolling
release. We have OBS, which is server software, connected to multiple builders.
It has projects and in those projects packages. Packages can have sources
somewhere in the git and git hook can trigger rebuild. Builds are done in new
cleanly installed environment (there is option to have some precached) which is
afterward thrown away. When package is built, all packages in the project that
depends on it are rebuild, unless there is no change to the package - it is
binary same as the last one (somebody fixed coding style?).

When package is send to Tumbleweed (rolling distro) it has to first build in
the project it is submitted from, then it is put into staging project where it
is built against clean Tumbleweed and packages depending on it from Tumbleweed
are rebuild.  Once done, staging project is run through automatic test and if
it passes, it is merged.

One more side note, OBS is opensource, it can build packages for multiple
architectures and distributions (openSUSE, SUSE, RHEL, Debian, ...) and they
accept patches to support more distributions :-)

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] List Prefix

[John Crispin]

On 05/05/2016 10:14, David Woodhouse wrote:
> On Thu, 2016-05-05 at 08:13 +0200, John Crispin wrote:
>>
>> Hi David,
>>
>> some folks would prefer to have the prefix on the 2 lists. I just had a
>> look in the mailman settings and failed to quickly spot the location
>> where this can be achieved.
> 
> Ick, they really ought to be able to handle that locally without
> polluting the subject header for everyone. But if you want to turn it
> back on, it's in the 'general options' page — the first one when you
> log in to the admin interface. About the fourth option down.
> 
> Or directly at
> http://lists.infradead.org/mailman/admin/lede-adm/?VARHELP=general/subject_prefix
> 

can this be turned on by subscribers manually for their subscription or
is there only one global option ? for the list ?

thanks for your time on this, i've never used mailman before.

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] List Prefix

[David Woodhouse]

On Thu, 2016-05-05 at 08:13 +0200, John Crispin wrote:
> 
> Hi David,
> 
> some folks would prefer to have the prefix on the 2 lists. I just had a
> look in the mailman settings and failed to quickly spot the location
> where this can be achieved.

Ick, they really ought to be able to handle that locally without
polluting the subject header for everyone. But if you want to turn it
back on, it's in the 'general options' page — the first one when you
log in to the admin interface. About the fourth option down.

Or directly at
http://lists.infradead.org/mailman/admin/lede-adm/?VARHELP=general/subject_prefix

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: getting users involved in on-device testing

[Michal Hrusecky]

John Crispin -  9:39  5.05.16 wrote:
> 
> 
> On 05/05/2016 09:10, Michal Hrusecky wrote:
> > John Crispin -  8:56  5.05.16 wrote:
> >> Hi,
> >>
> >> It would be nice if there was a process in place that would allow
> >> community members to easily be able to test images on devices and report
> >> the results some place. after some time thinking of different ways to do
> >> this I came up with one possible solution and wanted to know what others
> >> think about this.
> >>
> >> we setup a file similar to how the MAINTAINERS file in the kernel.
> >> anyone can add his name/email and boards he would like to be a tester
> >> of. every time an image is built for said board, an email is generated
> >> and sent out to the according persons. this email would contains an otp.
> >> with this credential you could then log into some web frontend and get a
> >> simple mask along the lines of
> >>
> >> * wifi worked
> >> * ethernet worked
> >> * leds worked
> >> * buttons worked
> >> * iperf
> >> * ssl benchmark
> >> ...
> >>
> >> this could all be done in a rather trivial manner and i dont think the
> >> work behind such a setup is really that huge. using otps would for
> >> example eliminate the need for user credential management. results could
> >> simply be stored in files on the backend and then harvested later by a
> >> secondary script etc etc...
> >>
> >> next it would be possible to generate static content based on aggregated
> >> data that will show a traffic light style support status for various
> >> boards, listing when it was last tested, with what revision and what the
> >> test results were.
> >>
> >> would something like this make sense ?
> > 
> > It kinda makes sense, although it would be even nicer if the tests were
> > automated as well. That is something that Purple is working on. There is a
> > BoardFarm[1] test framework that is designed to test routers and there 
> > could be
> > created test suites that reflects some of the criteria you described and in 
> > the
> > best case, whenever image is produced, automatic test could be triggered and
> > results uploaded. It outputs junit and there is plenty of parsers of junit 
> > - we
> > have it nicely integrated in Jenkins.
> > 
> > [1] https://github.com/qca/boardfarm
> 
> i doubt they will test the 900+ boards. i would expect them to test
> their own boards.

Yes, they probably wouldn't but as the software is opensource anybody can
deploy it and test his router. And they might end up have at some point test
results for tenths of routers. The project is just starting.
 
> additionally the proposal does not tell you how to test. it describes a
> way to notify when testing is required and where the images are located.
> i think you misread/understood the purpose of what i proposed or i
> worded it badly.

Yep I understand, I think that it is good idea. My mail was just to bring
awareness that there is something that can be used quite nicely on the
receiving end of those notifications to automate/speed up the testing and make
it easier. So making it easy to reply automatically would be nice ;-) And also
that it might be worth talking to and joining efforts with Prpl or Eric.

Just to note that there is somebody trying to achieve pretty much similar
results - having an idea how well OpenWRT/LEDE works on various routers ;-)

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: Proposal to sign all commits

[Foster Snowhill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05.05.16 10:08, David Lang wrote:
> In an environment where the vast majority of people are unknown, 
> and any signing they are doing involves no liability, and no 
> assurance that the person is who they claim to be (other than 
> claiming to be someone who has access to that signing key), the 
> value of signatures is much less.

Can't this problem be solved using the web of trust? It is doesn't
require a trusted certificate authority, thus is decentralized. Truth
be told, getting your key signed by others is not a simple process, as
it requires physical presence of both the signer and the one who gets
the signature, it's better than nothing though.


On 05.05.16 08:42, David Lang wrote:
> how do you handle cases where the maintainer needs to fix a merge 
> or otherwise tweak the submission?

As for commits, those shouldn't be edited, but a new commit should be
created with necessary fixes, carrying the signature of the person
doing the fixes. The original commit will have the signature of its
creator.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXKvdyAAoJECTakka9G8YAblQQAKBS+54Tj9AuJGmLbBsrejMP
cR3aMGfd2naReoUizI9/EisjD1aEDlzhcyeRZ575OokN8Z1iFtbAS2bfXrt40lej
RZfW2eXdo7Iwpay+sIuNQaqYg+dkE0T1L5M6/k3x1uHzH37Mw9p/6rJTypNXRusH
qT0ZvNUlLXikgD2VgfCuhzexmbX7kE5/adBHHl/kOXnldEdJBOCYHKkHFRHBEEdo
eya42OFcFHly633+bTQon7e8TqcPZwxarpOZBllpYNUqbEOVumCS6THoEjH98kbt
bUaKrmfZh097l0fW+KUBKD/kuZY4lDqOfwBbEp6SC4pwV4yHFUImvIAo4HYEHs25
I6OCFJh8nLPPGSUhau0EmM/iG2BX+PDbAEQjHx0RA8eMqsBUdLXVbbZTPRn+ffq/
nHlzqB50Ud5rc8RIMYHNYy2k8s6kd6awTd+rb/+i1rKUilvLz6CDtRQaQeKEAiKf
oXvMJnTOMFP3pCPP/pR93KH9PiGCJe3NYZf6wJYyKfo5YvZtBJW7jojcyhQ0MKrp
XXvjjRYpR3hjw10oKCaB1648FgfRlT4hlVhSmWDniaAEKyKIxon8LvBYFhVkqwZw
EqcccDsu2sp3Kk+zp961xIUda/ztrtxMeQiTIXUodTQBbIvy84obaPO73pexkoML
quVKJyPCJs7pAV9UU/Wf
=/FmW
-END PGP SIGNATURE-

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: List subject prefix?

[Hannu Nyman]

On 5.5.2016 9:59, David Woodhouse wrote:

It's the Mailman default, but it is deliberately disabled on this list
(as on many other technical lists where the members are expected to be
able to drive their email client properly).


That sounds pretty funny on 2010s when most of us use multiple devices to 
read mail. The list prefix makes it easier to quickly identify the general 
nature of a message on tablet/phone screen


Sure, we all can tinker with the desktop mail client classification rules, 
but not all mobile apps are that well adjustable. A short list prefix would 
make life more easy.



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: getting users involved in on-device testing

[Michal Hrusecky]

John Crispin -  8:56  5.05.16 wrote:
> Hi,
> 
> It would be nice if there was a process in place that would allow
> community members to easily be able to test images on devices and report
> the results some place. after some time thinking of different ways to do
> this I came up with one possible solution and wanted to know what others
> think about this.
> 
> we setup a file similar to how the MAINTAINERS file in the kernel.
> anyone can add his name/email and boards he would like to be a tester
> of. every time an image is built for said board, an email is generated
> and sent out to the according persons. this email would contains an otp.
> with this credential you could then log into some web frontend and get a
> simple mask along the lines of
> 
> * wifi worked
> * ethernet worked
> * leds worked
> * buttons worked
> * iperf
> * ssl benchmark
> ...
> 
> this could all be done in a rather trivial manner and i dont think the
> work behind such a setup is really that huge. using otps would for
> example eliminate the need for user credential management. results could
> simply be stored in files on the backend and then harvested later by a
> secondary script etc etc...
> 
> next it would be possible to generate static content based on aggregated
> data that will show a traffic light style support status for various
> boards, listing when it was last tested, with what revision and what the
> test results were.
> 
> would something like this make sense ?

It kinda makes sense, although it would be even nicer if the tests were
automated as well. That is something that Purple is working on. There is a
BoardFarm[1] test framework that is designed to test routers and there could be
created test suites that reflects some of the criteria you described and in the
best case, whenever image is produced, automatic test could be triggered and
results uploaded. It outputs junit and there is plenty of parsers of junit - we
have it nicely integrated in Jenkins.

[1] https://github.com/qca/boardfarm

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: List subject prefix?

[David Woodhouse]

On Wed, 2016-05-04 at 17:31 -0400, Aaron Z wrote:
> On many (most?) mailing lists, there is a prefix on all subjects
> which has the list name (such as [OpenWRT-Devel])
> Can this prefix be added for this list (or is that an option that I
> missed when I signed up)?

It's the Mailman default, but it is deliberately disabled on this list
(as on many other technical lists where the members are expected to be
able to drive their email client properly).

There are much better things to filter list traffic on — the SMTP
reverse-path (often in a Return-Path: header after delivery) is most
reliable, or the various standard List-* headers that the list adds,
which kind of work for most of the common cases.

If you really want list traffic in your inbox instead of a separate
folder, and you want to mark it differently, then you should be able to
do that locally instead of polluting the Subject header with redundant
information that obscures the *real* subject that the sender typed, for
everyone.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] List Prefix

[John Crispin]

On 27/04/2016 10:47, John Crispin wrote:
> 
> 
> On 26/04/2016 18:51, David Woodhouse wrote:
>> On Tue, 2016-04-26 at 17:16 +0200, Jo-Philipp Wich wrote:
>>> This is just a test, please ignore.
>>
>> Hm, I thought I fixed the stupid mailman default when I set up the
>> list, to remove the pointless [LEDE-DEV] pollution from the subject
>> line. There are *proper* list headers to indicate that it's mailing
>> list traffic, without obscuring the subject.
>>
>> Shall I go fix it... or *had* I done so once, and you broke it again...
>> in which case can I ask you to reconsider?
> 
> please fix it if you have the time :-) i did play with the settings a
> bit to get the moderation working properly and probably b0rked it on the
> way.
> 
>   John

Hi David,

some folks would prefer to have the prefix on the 2 lists. I just had a
look in the mailman settings and failed to quickly spot the location
where this can be achieved. could you flick the switch back please ?

Johnu

> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev