Re: [LEDE-DEV] openwrt and lede - remerge proposal

2017-05-08 Thread A. Benz via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Who among our resident young-timers knows XMMS? Once upon a time this 
was a household name (FOSS folks houses). Now I reckon those who use it 
as a primary player do it for nostalgia.


Likewise, OpenWRT while more recognizable than LEDE, is not worth as 
much as people here paint it, and will only remain relevant as long as 
people keep using it. Market/brand concept (in retail) doesn't really apply.


Indifferent what name this project ends up using, just that LEDE (Linux 
Embedded Dev. Environment) expands the scope beyond routers, and breaks 
free from the "WRT" implication of wireless routers (does LEDE still 
have any of the original WRT source release by linksys?).


LEDE sounds more fitting and gives the impression of a proper distro, 
which it is, rather than an improved fork/clone of an ancient source dump.


No biggie, just thought I'd chime in. Good luck all.

Regards,
A. Benz

On 05/09/17 09:33, Eric Luehrsen wrote:

  From a raw objective stand, OpenWrt has better market value as a brand.
Its longer lived on the net and more unique audibly. If we surveyed 1000
somewhat technical people, then we would have way more recognition hits.
I realize the vote concluded already, but hopefully this thought helps
ease some less happy minds.


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

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.9 to 4.9.25

2017-05-08 Thread Alexandru Ardelean 
Hey,

You can also Reject your patch here:
http://patchwork.ozlabs.org/project/lede/list/

Specifically, this patch is:
http://patchwork.ozlabs.org/patch/756400/

And [for reference] you can see all patches submitted by you [from
your email account]:
http://patchwork.ozlabs.org/project/lede/list/?submitter=69184=*===

The email list is indexed in that tool.

You do need to create an account.
But it's a simple process ; should not require too many personal details.

Patchwork is still partially used for tracking some patches sent via email.
Tho, I will admit, I'm more of a fan of the Github PR process.

Alex


On Mon, May 8, 2017 at 10:29 AM, Koen Vandeputte
 wrote:
> Dear,
>
> Please cancel this patch
>
>
> Since this was submitted:
>
> - 4.9.27 already arrived
> - Some other kernel patches have been submitted or got staged after this
> patch was created
>
> Logically, this one will now not apply anymore.
>
>
> Koen
>
> On 2017-04-28 15:17, Koen Vandeputte wrote:
>>
>> - Refresh all patches
>> - Removed upstreamed
>> - Adapted 1
>>
>> Compiled & Tested on targets: cns3xxx & imx6
>>
>> Signed-off-by: Koen Vandeputte 
>> ---
>>   include/kernel-version.mk  |   4 +-
>>   .../802-usb-xhci-force-msi-renesas-xhci.patch  |   2 +-
>>   ...X-Add-back-handler-ignoring-external-impr.patch |  75 
>>   ...-BCM5301X-Correct-GIC_PPI-interrupt-flags.patch |  41 ---
>>   ...ave-host-bridge-window-resource-in-struct.patch | 131
>> -
>>   ...-add-support-for-performing-fake-doorbell.patch |  10 +-
>>   .../patches-4.9/905-BCM53573-minor-hacks.patch |   2 +-
>>   .../patches-4.9/950-0031-Add-dwc_otg-driver.patch  |   2 +-
>>   ...-thermal-driver-for-reporting-core-temper.patch |   2 +-
>>   ...le-CONFIG_MEMCG-but-leave-it-disabled-due.patch |   4 +-
>>   ...-Fix-hang-for-writing-messages-larger-tha.patch |  90 --
>>   .../031-ubifs-fix-RENAME_WHITEOUT-support.patch|  25 
>>   .../040-01-MIPS-Introduce-irq_stack.patch  |  70 ---
>>   ...2-MIPS-Stack-unwinding-while-on-IRQ-stack.patch |  42 ---
>>   ...hange-28-to-thread_info-if-coming-from-us.patch |  48 
>>   ...IPS-Switch-to-the-irq_stack-in-interrupts.patch | 116
>> --
>>   ...05-MIPS-Select-HAVE_IRQ_EXIT_ON_IRQ_STACK.patch |  21 
>>   ...ack-Fix-erroneous-jal-to-plat_irq_dispatc.patch |  35 --
>>   ...part-fix-parsing-first-block-after-aligne.patch |  40 ---
>>   ...jecting-with-source-address-failed-policy.patch |  16 +--
>>   .../810-pci_disable_common_quirks.patch|   6 +-
>>   .../generic/patches-4.9/904-debloat_dma_buf.patch  |   2 +-
>>   ...sdhc-imx-increase-the-pad-I-O-drive-stren.patch |  42 ---
>>   ...om-use-scm_call-to-route-GPIO-irq-to-Apps.patch |   2 +-
>>   .../0008-MIPS-lantiq-backport-old-timer-code.patch |   2 +-
>>   ...-lantiq-wifi-and-ethernet-eeprom-handling.patch |   2 +-
>>   ...soc-mediatek-Add-MT2701-power-dt-bindings.patch |  10 +-
>>   ...k-Refine-scpsys-to-support-multiple-platf.patch |  19 ++-
>>   ...015-soc-mediatek-Add-MT2701-scpsys-driver.patch |  12 +-
>>   .../patches-4.9/0071-pwm-add-pwm-mediatek.patch|  16 +--
>>   .../linux/mediatek/patches-4.9/0083-mfd-led3.patch |   4 +-
>>   .../mediatek/patches-4.9/0085-pmic-led0.patch  |   3 -
>>   .../mediatek/patches-4.9/0086-pmic-led1.patch  |   4 +-
>>   .../mediatek/patches-4.9/0087-pmic-led2.patch  |  10 +-
>>   .../mediatek/patches-4.9/0088-pmic-led3.patch  |   4 +-
>>   target/linux/mediatek/patches-4.9/0091-dsa1.patch  |   3 -
>>   .../0091-net-next-mediatek-fix-DQL-support.patch   |   6 +-
>>   target/linux/mediatek/patches-4.9/0092-dsa2.patch  |  23 +---
>>   target/linux/mediatek/patches-4.9/0092-dsa3.patch  |   6 +-
>>   target/linux/mediatek/patches-4.9/0092-dsa4.patch  |   4 +-
>>   target/linux/mediatek/patches-4.9/0092-dsa5.patch  |  16 +--
>>   .../mediatek/patches-4.9/0093-dsa-compat.patch |  18 +--
>>   .../mediatek/patches-4.9/0094-net-affinity.patch   |  12 +-
>>   target/linux/mediatek/patches-4.9/0095-ephy.patch  |  12 +-
>>   .../mediatek/patches-4.9/0096-dsa-multi-cpu.patch  |  30 ++---
>>   .../mediatek/patches-4.9/0097-dsa-mt7530.patch |   6 +-
>>   .../patches-4.9/200-rt3883-fix-pinctrl-typo.patch  |  21 
>>   47 files changed, 91 insertions(+), 980 deletions(-)
>>   delete mode 100644
>> target/linux/bcm53xx/patches-4.9/031-ARM-BCM5301X-Add-back-handler-ignoring-external-impr.patch
>>   delete mode 100644
>> target/linux/bcm53xx/patches-4.9/033-0013-ARM-dts-BCM5301X-Correct-GIC_PPI-interrupt-flags.patch
>>   delete mode 100644
>> target/linux/bcm53xx/patches-4.9/089-PCI-iproc-Save-host-bridge-window-resource-in-struct.patch
>>   delete mode 100644
>> target/linux/brcm2708/patches-4.9/950-0106-i2c-bcm2835-Fix-hang-for-writing-messages-larger-tha.patch
>>   delete mode 100644
>>

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.9 to 4.9.25

2017-05-08 Thread Koen Vandeputte 



On 2017-05-08 09:36, Alexandru Ardelean wrote:

Hey,

You can also Reject your patch here:
http://patchwork.ozlabs.org/project/lede/list/

Specifically, this patch is:
http://patchwork.ozlabs.org/patch/756400/

And [for reference] you can see all patches submitted by you [from
your email account]:
http://patchwork.ozlabs.org/project/lede/list/?submitter=69184=*===

The email list is indexed in that tool.

You do need to create an account.
But it's a simple process ; should not require too many personal details.

Patchwork is still partially used for tracking some patches sent via email.
Tho, I will admit, I'm more of a fan of the Github PR process.

Alex



Done
Thanks Alex.


Koen

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

Re: [LEDE-DEV] [PATCH] kernel: update kernel 4.9 to 4.9.25

2017-05-08 Thread Koen Vandeputte 

Dear,

Please cancel this patch


Since this was submitted:

- 4.9.27 already arrived
- Some other kernel patches have been submitted or got staged after this 
patch was created


Logically, this one will now not apply anymore.


Koen

On 2017-04-28 15:17, Koen Vandeputte wrote:

- Refresh all patches
- Removed upstreamed
- Adapted 1

Compiled & Tested on targets: cns3xxx & imx6

Signed-off-by: Koen Vandeputte 
---
  include/kernel-version.mk  |   4 +-
  .../802-usb-xhci-force-msi-renesas-xhci.patch  |   2 +-
  ...X-Add-back-handler-ignoring-external-impr.patch |  75 
  ...-BCM5301X-Correct-GIC_PPI-interrupt-flags.patch |  41 ---
  ...ave-host-bridge-window-resource-in-struct.patch | 131 -
  ...-add-support-for-performing-fake-doorbell.patch |  10 +-
  .../patches-4.9/905-BCM53573-minor-hacks.patch |   2 +-
  .../patches-4.9/950-0031-Add-dwc_otg-driver.patch  |   2 +-
  ...-thermal-driver-for-reporting-core-temper.patch |   2 +-
  ...le-CONFIG_MEMCG-but-leave-it-disabled-due.patch |   4 +-
  ...-Fix-hang-for-writing-messages-larger-tha.patch |  90 --
  .../031-ubifs-fix-RENAME_WHITEOUT-support.patch|  25 
  .../040-01-MIPS-Introduce-irq_stack.patch  |  70 ---
  ...2-MIPS-Stack-unwinding-while-on-IRQ-stack.patch |  42 ---
  ...hange-28-to-thread_info-if-coming-from-us.patch |  48 
  ...IPS-Switch-to-the-irq_stack-in-interrupts.patch | 116 --
  ...05-MIPS-Select-HAVE_IRQ_EXIT_ON_IRQ_STACK.patch |  21 
  ...ack-Fix-erroneous-jal-to-plat_irq_dispatc.patch |  35 --
  ...part-fix-parsing-first-block-after-aligne.patch |  40 ---
  ...jecting-with-source-address-failed-policy.patch |  16 +--
  .../810-pci_disable_common_quirks.patch|   6 +-
  .../generic/patches-4.9/904-debloat_dma_buf.patch  |   2 +-
  ...sdhc-imx-increase-the-pad-I-O-drive-stren.patch |  42 ---
  ...om-use-scm_call-to-route-GPIO-irq-to-Apps.patch |   2 +-
  .../0008-MIPS-lantiq-backport-old-timer-code.patch |   2 +-
  ...-lantiq-wifi-and-ethernet-eeprom-handling.patch |   2 +-
  ...soc-mediatek-Add-MT2701-power-dt-bindings.patch |  10 +-
  ...k-Refine-scpsys-to-support-multiple-platf.patch |  19 ++-
  ...015-soc-mediatek-Add-MT2701-scpsys-driver.patch |  12 +-
  .../patches-4.9/0071-pwm-add-pwm-mediatek.patch|  16 +--
  .../linux/mediatek/patches-4.9/0083-mfd-led3.patch |   4 +-
  .../mediatek/patches-4.9/0085-pmic-led0.patch  |   3 -
  .../mediatek/patches-4.9/0086-pmic-led1.patch  |   4 +-
  .../mediatek/patches-4.9/0087-pmic-led2.patch  |  10 +-
  .../mediatek/patches-4.9/0088-pmic-led3.patch  |   4 +-
  target/linux/mediatek/patches-4.9/0091-dsa1.patch  |   3 -
  .../0091-net-next-mediatek-fix-DQL-support.patch   |   6 +-
  target/linux/mediatek/patches-4.9/0092-dsa2.patch  |  23 +---
  target/linux/mediatek/patches-4.9/0092-dsa3.patch  |   6 +-
  target/linux/mediatek/patches-4.9/0092-dsa4.patch  |   4 +-
  target/linux/mediatek/patches-4.9/0092-dsa5.patch  |  16 +--
  .../mediatek/patches-4.9/0093-dsa-compat.patch |  18 +--
  .../mediatek/patches-4.9/0094-net-affinity.patch   |  12 +-
  target/linux/mediatek/patches-4.9/0095-ephy.patch  |  12 +-
  .../mediatek/patches-4.9/0096-dsa-multi-cpu.patch  |  30 ++---
  .../mediatek/patches-4.9/0097-dsa-mt7530.patch |   6 +-
  .../patches-4.9/200-rt3883-fix-pinctrl-typo.patch  |  21 
  47 files changed, 91 insertions(+), 980 deletions(-)
  delete mode 100644 
target/linux/bcm53xx/patches-4.9/031-ARM-BCM5301X-Add-back-handler-ignoring-external-impr.patch
  delete mode 100644 
target/linux/bcm53xx/patches-4.9/033-0013-ARM-dts-BCM5301X-Correct-GIC_PPI-interrupt-flags.patch
  delete mode 100644 
target/linux/bcm53xx/patches-4.9/089-PCI-iproc-Save-host-bridge-window-resource-in-struct.patch
  delete mode 100644 
target/linux/brcm2708/patches-4.9/950-0106-i2c-bcm2835-Fix-hang-for-writing-messages-larger-tha.patch
  delete mode 100644 
target/linux/generic/patches-4.9/031-ubifs-fix-RENAME_WHITEOUT-support.patch
  delete mode 100644 
target/linux/generic/patches-4.9/040-01-MIPS-Introduce-irq_stack.patch
  delete mode 100644 
target/linux/generic/patches-4.9/040-02-MIPS-Stack-unwinding-while-on-IRQ-stack.patch
  delete mode 100644 
target/linux/generic/patches-4.9/040-03-MIPS-Only-change-28-to-thread_info-if-coming-from-us.patch
  delete mode 100644 
target/linux/generic/patches-4.9/040-04-MIPS-Switch-to-the-irq_stack-in-interrupts.patch
  delete mode 100644 
target/linux/generic/patches-4.9/040-05-MIPS-Select-HAVE_IRQ_EXIT_ON_IRQ_STACK.patch
  delete mode 100644 
target/linux/generic/patches-4.9/040-06-MIPS-IRQ-Stack-Fix-erroneous-jal-to-plat_irq_dispatc.patch
  delete mode 100644 
target/linux/generic/patches-4.9/060-0001-mtd-bcm47xxpart-fix-parsing-first-block-after-aligne.patch
  delete mode 100644

[LEDE-DEV] [PATCH] kernel: update kernel 4.9 to 4.9.27

2017-05-08 Thread Koen Vandeputte 
- Refresh all patches
- Removed upstreamed
- Adapted 1

Compile tested on: bcm53xx, cns3xxx, imx6
Run tested on: cns3xxx & imx6

Signed-off-by: Koen Vandeputte 
---
 include/kernel-version.mk  |   4 +-
 .../802-usb-xhci-force-msi-renesas-xhci.patch  |   2 +-
 ...stmmac-Disable-frame-filtering-completely.patch |   4 +-
 ...stmmac-Disable-frame-filtering-completely.patch |   4 +-
 ...X-Add-back-handler-ignoring-external-impr.patch |  75 
 ...-BCM5301X-Correct-GIC_PPI-interrupt-flags.patch |  41 ---
 ...ave-host-bridge-window-resource-in-struct.patch | 131 -
 ...-add-support-for-performing-fake-doorbell.patch |  10 +-
 .../patches-4.9/905-BCM53573-minor-hacks.patch |   2 +-
 .../patches-4.9/950-0031-Add-dwc_otg-driver.patch  |   2 +-
 ...-thermal-driver-for-reporting-core-temper.patch |   2 +-
 ...le-CONFIG_MEMCG-but-leave-it-disabled-due.patch |   4 +-
 ...-Fix-hang-for-writing-messages-larger-tha.patch |  90 --
 ...12-usb-Make-sure-usb-phy-of-gets-built-in.patch |   7 +-
 .../031-ubifs-fix-RENAME_WHITEOUT-support.patch|  25 
 .../040-01-MIPS-Introduce-irq_stack.patch  |  70 ---
 ...2-MIPS-Stack-unwinding-while-on-IRQ-stack.patch |  42 ---
 ...hange-28-to-thread_info-if-coming-from-us.patch |  48 
 ...IPS-Switch-to-the-irq_stack-in-interrupts.patch | 116 --
 ...05-MIPS-Select-HAVE_IRQ_EXIT_ON_IRQ_STACK.patch |  21 
 ...ack-Fix-erroneous-jal-to-plat_irq_dispatc.patch |  35 --
 ...part-fix-parsing-first-block-after-aligne.patch |  40 ---
 .../patches-4.9/630-packet_socket_type.patch   |   4 +-
 .../666-Add-support-for-MAP-E-FMRs-mesh-mode.patch |  22 ++--
 ...jecting-with-source-address-failed-policy.patch |  18 +--
 .../generic/patches-4.9/701-phy_extension.patch|   2 +-
 .../710-phy-add-mdio_register_board_info.patch |   2 +-
 .../810-pci_disable_common_quirks.patch|   6 +-
 .../generic/patches-4.9/904-debloat_dma_buf.patch  |   2 +-
 ...sdhc-imx-increase-the-pad-I-O-drive-stren.patch |  42 ---
 ...om-use-scm_call-to-route-GPIO-irq-to-Apps.patch |   2 +-
 .../0008-MIPS-lantiq-backport-old-timer-code.patch |   2 +-
 .../patches-4.9/0026-NET-multi-phy-support.patch   |   6 +-
 ...-lantiq-wifi-and-ethernet-eeprom-handling.patch |   2 +-
 .../patches-4.9/0001-NET-multi-phy-support.patch   |   6 +-
 ...soc-mediatek-Add-MT2701-power-dt-bindings.patch |  10 +-
 ...k-Refine-scpsys-to-support-multiple-platf.patch |  19 ++-
 ...015-soc-mediatek-Add-MT2701-scpsys-driver.patch |  12 +-
 .../patches-4.9/0071-pwm-add-pwm-mediatek.patch|  16 +--
 .../linux/mediatek/patches-4.9/0083-mfd-led3.patch |   4 +-
 .../mediatek/patches-4.9/0085-pmic-led0.patch  |   3 -
 .../mediatek/patches-4.9/0086-pmic-led1.patch  |   4 +-
 .../mediatek/patches-4.9/0087-pmic-led2.patch  |  10 +-
 .../mediatek/patches-4.9/0088-pmic-led3.patch  |   4 +-
 target/linux/mediatek/patches-4.9/0091-dsa1.patch  |   3 -
 .../0091-net-next-mediatek-fix-DQL-support.patch   |   6 +-
 target/linux/mediatek/patches-4.9/0092-dsa2.patch  |  23 +---
 target/linux/mediatek/patches-4.9/0092-dsa3.patch  |   6 +-
 target/linux/mediatek/patches-4.9/0092-dsa4.patch  |   4 +-
 target/linux/mediatek/patches-4.9/0092-dsa5.patch  |  16 +--
 .../mediatek/patches-4.9/0093-dsa-compat.patch |  18 +--
 .../mediatek/patches-4.9/0094-net-affinity.patch   |  12 +-
 target/linux/mediatek/patches-4.9/0095-ephy.patch  |  12 +-
 .../mediatek/patches-4.9/0096-dsa-multi-cpu.patch  |  30 ++---
 .../mediatek/patches-4.9/0097-dsa-mt7530.patch |   6 +-
 ...erpc-85xx-add-gpio-keys-to-of-match-table.patch |   2 +-
 .../100-powerpc-85xx-tl-wdr4900-v1-support.patch   |   4 +-
 ...ovide-a-hook-for-link-up-link-down-events.patch |  18 +--
 ...-phy-move-phy-MMD-accessors-to-phy-core.c.patch |   2 +-
 ...oid-setting-unsupported-EEE-advertisments.patch |   2 +-
 ...tart-phy-autonegotiation-after-EEE-advert.patch |   2 +-
 ...-phy-allow-EEE-with-SGMII-interface-modes.patch |   2 +-
 ...hook-up-clause-45-autonegotiation-restart.patch |   2 +-
 ...-phy-export-phy_start_machine-for-phylink.patch |   2 +-
 .../patches-4.9/0034-NET-multi-phy-support.patch   |   6 +-
 .../patches-4.9/200-rt3883-fix-pinctrl-typo.patch  |  21 
 66 files changed, 139 insertions(+), 1033 deletions(-)
 delete mode 100644 
target/linux/bcm53xx/patches-4.9/031-ARM-BCM5301X-Add-back-handler-ignoring-external-impr.patch
 delete mode 100644 
target/linux/bcm53xx/patches-4.9/033-0013-ARM-dts-BCM5301X-Correct-GIC_PPI-interrupt-flags.patch
 delete mode 100644 
target/linux/bcm53xx/patches-4.9/089-PCI-iproc-Save-host-bridge-window-resource-in-struct.patch
 delete mode 100644 
target/linux/brcm2708/patches-4.9/950-0106-i2c-bcm2835-Fix-hang-for-writing-messages-larger-tha.patch
 delete mode 100644 
target/linux/generic/patches-4.9/031-ubifs-fix-RENAME_WHITEOUT-support.patch
 delete mode 100644

Re: [LEDE-DEV] openwrt and lede - remerge proposal

2017-05-08 Thread Zoltan HERPAI 

Hi,

On Mon, 8 May 2017, Daniel Engberg wrote:


Trac:
Is it really worth keeping trac at all? What value does it add? Just display 
a page explaining that it's shutdown and forward to OpenWrt?


There is a lot of "added value" in the tickets submitted throughout the 
years, either as comments, notes, fixes or just the issue being raised, so
it's a good idea to keep it for archiving purposes. Older devices do die, 
but every year or so I come across shops selling brand new WRT54G 
(really), so keeping the knowledge base in an unsorted form (compared to a 
wiki) to the users can be useful. Whether that's a staticized archive or 
running the trac engine itself is another question.


Other than that, I very much welcome the groundwork for the planned merge 
- thanks John, Imre and Felix for putting it together.


Regards,
Zoltan H

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

Re: [LEDE-DEV] openwrt and lede - remerge proposal

2017-05-08 Thread Peter Ziobrzynski 
I think it is a great news that openwrt/lede governance is merging back
together. I was really worried. There is not that many of you that can
run a complex project like that.

>From my side what matters is to be able to take the last release and
build it from source for my use. I found lede 17 release in much better
shape than openwrt 15.  I hope you will keep the lede momentum.

-p


On 5/8/2017 7:19 AM, John Crispin wrote:
> Hi,
>
> Felix, Imre and myself had 2 calls last week lasting several hours and
> discussed the following proposal of conditions for a remerge that we
> would like to propose and have people vote on.
>
> *) branding
> - the owrt side sees no option of using the lede brand
>
> - a (minor) majority voted for openwrt as a name over lede whilst most
> people said they did not care
>
> - as the last vote had a 100% ACK for a remerge using the owrt brand
> is the only feasible option
>
> *) domain
> - transfer owner ship to SPI for openwrt.org and lede-project.org
> - add them to the pool of urls at digital ocean
> - post remerge build a setup where we have several DNS servers in
> various locations
> - point git.openwrt.org at the lede git server
> - point bugs.openwrt.org to the lede flyspray instance
> - keep both wikis and forums as is (we should decide post remerge how
> to proceed to avoid these issues blocking the progress)
> - update the lede domain entries for build/download/rsync/... servers
> so that the openwrt domain also points at them
>
> *) SPI
> - TBD post remerge
>
> *) github
> - stop pushing to lede-project organisation
> - start pushing to the openwrt organisation
> - cleanup the list of owners in the openwrt organisation
> - obsolete all issues on the openwrt organisation and close the issue
> tracker
> - go through the open openwrt and lede PRs, pickup whats useful and
> close the rest, asking people to repost (things wont be rebasable anyhow)
> - close the lede PR tracker
> - keep the lede organisation in its current state so that forked trees
> dont get obsoleted
>
> - obsolete the lede github org after a grace period of 3-6 months
>
> *) landing page
> - update the lede landing page to represent the openwrt name
> - update the landing page to have the same look & feel as the current
> openwrt landing page
> - point openwrt.org at the lede landing page
>
> *) trac
> - trac is already readonly, keep content so that search engines can
> still find the it
> - edit the trac html templates, adding a note pointing at the
> bug.openwrt.org instance
>
> *) email accounts
> - currently there are around ~20 active openwrt.org mail accounts
> - turn all the webmaster@, hostmaster@, ... accounts into aliases that
> anyone with voting rights can be subscribed to
> - ask those people that are no longer active to voluntarily give up
> their accounts
> - mail addresses may under no conditions be used for any personal
> business, consultancy, applying for jobs, ... purposes
>
> - any mail sent from an openwrt.org account needs to adhere the
> trademark policy and should only be used for FOSS purposes
>
>
> *) wiki / forum
> - TBD
> - asking in either forum/wiki will get a biased vote so keep them both
> around
> - start a separate discussion regarding these post remerge
>
> *) LF
> - find out what doubts folks have about LF
> - find out benefits - we would have their hosting and sponsorship ?!
> - start a separate discussion regarding these post remerge
>
> *) git trees
> - rebrand the lede tree to openwrt
> - work out what has happened inside the openwrt tree since the reboot
> and pick up the useful bits (zoltan has done some prior work on this
> already)
>
> *) mailing list
> - ask david to add the openwrt-adm and openwrt lists
> - announce the switch to the infradead serves, asking people to
> unsubscribe if they have privacy issues with this
> - import the user DB from the current openwrt and lede ML into the 2
> new mailing lists
> - find out if we can redirect/auto-reply  the existing lists to the
> new ones
>
> *) trademark/sponsorship policy
> - review/ack imres trademark policy
> - review/ack jows sponsorship policy
>
> *) timeline
> - refine / vote / agree on the proposal withing the next 2 week
> - work on the action items in the 4 weeks after that
>
> John
>
>
> ___
> lede-adm mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm

-- 
Peter Ziobrzynski, mailto:p...@pzi.net



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

Re: [LEDE-DEV] openwrt and lede - remerge proposal

2017-05-08 Thread Imre Kaloz 

On 2017-05-08 15:43, Toke Høiland-Jørgensen wrote:

John Crispin  writes:


Hi,

Felix, Imre and myself had 2 calls last week lasting several hours and discussed
the following proposal of conditions for a remerge that we would like to propose
and have people vote on.


Great to hear progress is being made on this! I think the proposal looks
reasonable, generally. A few comments / questions:

- What will this mean for the community rules and the release schedule?
  Will they continue from the current LEDE practices?


- update the landing page to have the same look & feel as the current openwrt
landing page


Well, I like the L of lede-project.org better - but it's not something
worth bikeshedding over, so meh, fine... ;)


Well, the OpenWrt one might be from 2000s, but the LEDE one is from '95 
;) I think the CSS jow did for the OpenWrt forum looks the best TBH :)



*) trademark/sponsorship policy
- review/ack imres trademark policy
- review/ack jows sponsorship policy


Links to these?


On the tm policy: https://openwrt.org/trademark - I guess jow will chime 
in with the location of the sponsorship one, too.





Imre

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

Re: [LEDE-DEV] [PATCH] ipq806x: Add nand boot support for ipq40xx AP-DK04.1-C1

2017-05-08 Thread Ram Chandra Jangir 
Hi Christian,

>Hello,


 On Saturday, May 06, 2017 11:24 PM  Christian Lamparter wrote:
>On Friday, May 5, 2017 9:19:36 PM CEST Ram Chandra Jangir wrote:
> This change add nand boot support for IPQ40xx based
> AP-DK04.1-C1 board using ubi image, also add sysupgrage support for 
> AP-DK04.1-C1 and generates a sysupgrade.tar image.
> 
> Testing:
> *Tested on IPQ40xx AP-DK04.1-C1 and IPQ806x AP148 Board:
>   a. NAND boot
>   b. ubi sysupgrade
> 
> Signed-off-by: Ram Chandra Jangir 

>Thanks for posting this.

>Chris Blake is currently in the process of adding the Cisco Meraki MR33.
>
>The MR33 uses the IPQ4029 and has just a Spansion S34ML01G200TFV00 128MiB
NAND Flash for storage.

>He reported that with this patch attached. The driver is loading, but it
can't access the nand: 

>[0.860703] nand: second ID read did not match 7f,7f against 01,71
>[0.861633] nand: No NAND device found

>The id is supposed to be 01 (manuf = Spanion), f1 (128MiB).
>both readings are bad.

>I think this is caused by two problems:

>1. 7f, 7f should be 0xff, 0xff. 0x71 should be 0xf1.

>2. It seems that the NAND chip was not ready on the first read. 

>I strongly suspect (due to the MSB error for BIT 7), that at least one I/O
line is missing due to a bad pinctrl/mux setup.

>Could you please add the pinctrl nand definitions to the dts so he can test
again?

>Regards,
>Christian

IPQ4019 (ex. AP-DK04.1-C1) boards will  have nand boot mode with a dedicated
jumper settings.  Based on nand boot jumper settings change, HW will
automatically take care of initializing  the nand_pins mux at boot time.
That is why  we don't need to do initialization of  pinmux in ipq4019 kernel
boot/dts.   Currently I don't have Cisco Meraki MR33 board with me to give a
try.
I  will give a try for nor-nand  boot on ipq4019 with pinmux initialization
and will update you, if it helps you.

Thanks,
Ram




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

Re: [LEDE-DEV] openwrt and lede - remerge proposal

2017-05-08 Thread Paul Oranje 

> Op 8 mei 2017, om 15:19 heeft John Crispin  het volgende 
> geschreven:
> 
> Hi,
> 
> Felix, Imre and myself had 2 calls last week lasting several hours and 
> discussed the following proposal of conditions for a remerge that we would 
> like to propose and have people vote on.
Is a recording or transcription of these talks available ?

Paul



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

Re: [LEDE-DEV] openwrt and lede - remerge proposal

2017-05-08 Thread Vincenzo Romano 
2017-05-08 15:43 GMT+02:00 Toke Høiland-Jørgensen :
> John Crispin  writes:
>
>> Hi,
>>
>> Felix, Imre and myself had 2 calls last week lasting several hours and 
>> discussed
>> the following proposal of conditions for a remerge that we would like to 
>> propose
>> and have people vote on.
>
> Great to hear progress is being made on this! I think the proposal looks
> reasonable, generally. A few comments / questions:
>
> - What will this mean for the community rules and the release schedule?
>   Will they continue from the current LEDE practices?
>
>> - update the landing page to have the same look & feel as the current openwrt
>> landing page
>
> Well, I like the L of lede-project.org better - but it's not something
> worth bikeshedding over, so meh, fine... ;)
>
>> *) trademark/sponsorship policy
>> - review/ack imres trademark policy
>> - review/ack jows sponsorship policy
>
> Links to these?
>
> -Toke

i think we can:

1. keep the OpenWRT brand (already voted),
2. integrate most of the stuff of the two projects (like the nice ToH
and the device-specific pages),
3. choose the LEDE L, provided that the majority cares about it (to be voted).

--
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
NON QVIETIS MARIBVS NAVTA PERITVS

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

[LEDE-DEV] openwrt and lede - remerge proposal

2017-05-08 Thread John Crispin 

Hi,

Felix, Imre and myself had 2 calls last week lasting several hours and 
discussed the following proposal of conditions for a remerge that we 
would like to propose and have people vote on.


*) branding
- the owrt side sees no option of using the lede brand

- a (minor) majority voted for openwrt as a name over lede whilst most 
people said they did not care


- as the last vote had a 100% ACK for a remerge using the owrt brand is 
the only feasible option


*) domain
- transfer owner ship to SPI for openwrt.org and lede-project.org
- add them to the pool of urls at digital ocean
- post remerge build a setup where we have several DNS servers in 
various locations

- point git.openwrt.org at the lede git server
- point bugs.openwrt.org to the lede flyspray instance
- keep both wikis and forums as is (we should decide post remerge how to 
proceed to avoid these issues blocking the progress)
- update the lede domain entries for build/download/rsync/... servers so 
that the openwrt domain also points at them


*) SPI
- TBD post remerge

*) github
- stop pushing to lede-project organisation
- start pushing to the openwrt organisation
- cleanup the list of owners in the openwrt organisation
- obsolete all issues on the openwrt organisation and close the issue 
tracker
- go through the open openwrt and lede PRs, pickup whats useful and 
close the rest, asking people to repost (things wont be rebasable anyhow)

- close the lede PR tracker
- keep the lede organisation in its current state so that forked trees 
dont get obsoleted


- obsolete the lede github org after a grace period of 3-6 months

*) landing page
- update the lede landing page to represent the openwrt name
- update the landing page to have the same look & feel as the current 
openwrt landing page

- point openwrt.org at the lede landing page

*) trac
- trac is already readonly, keep content so that search engines can 
still find the it
- edit the trac html templates, adding a note pointing at the 
bug.openwrt.org instance


*) email accounts
- currently there are around ~20 active openwrt.org mail accounts
- turn all the webmaster@, hostmaster@, ... accounts into aliases that 
anyone with voting rights can be subscribed to
- ask those people that are no longer active to voluntarily give up 
their accounts
- mail addresses may under no conditions be used for any personal 
business, consultancy, applying for jobs, ... purposes


- any mail sent from an openwrt.org account needs to adhere the 
trademark policy and should only be used for FOSS purposes



*) wiki / forum
- TBD
- asking in either forum/wiki will get a biased vote so keep them both 
around

- start a separate discussion regarding these post remerge

*) LF
- find out what doubts folks have about LF
- find out benefits - we would have their hosting and sponsorship ?!
- start a separate discussion regarding these post remerge

*) git trees
- rebrand the lede tree to openwrt
- work out what has happened inside the openwrt tree since the reboot 
and pick up the useful bits (zoltan has done some prior work on this 
already)


*) mailing list
- ask david to add the openwrt-adm and openwrt lists
- announce the switch to the infradead serves, asking people to 
unsubscribe if they have privacy issues with this
- import the user DB from the current openwrt and lede ML into the 2 new 
mailing lists

- find out if we can redirect/auto-reply  the existing lists to the new ones

*) trademark/sponsorship policy
- review/ack imres trademark policy
- review/ack jows sponsorship policy

*) timeline
- refine / vote / agree on the proposal withing the next 2 week
- work on the action items in the 4 weeks after that

John


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

Re: [LEDE-DEV] openwrt and lede - remerge proposal

2017-05-08 Thread David Woodhouse 
On Mon, 2017-05-08 at 15:19 +0200, John Crispin wrote:
> 
> *) mailing list
> - ask david to add the openwrt-adm and openwrt lists
> - announce the switch to the infradead serves, asking people to 
> unsubscribe if they have privacy issues with this
> - import the user DB from the current openwrt and lede ML into the 2 new 
> mailing lists
> - find out if we can redirect/auto-reply  the existing lists to the new ones

Yes, we can redirect the existing lists to the new ones — so for
example, mail sent to lede-dev will just turn up on the openwrt-dev
list instead. Assuming that's what you meant.

For importing subscribers, if that's what you want to do, I'd be
inclined to send *invitations* not just subscribe people. So each
person will get the 'someone has requested that your address be
subscribed; click here to actually do it' message. We can write our own
blurb to go out at the top of those invitations.

I still haven't worked out if I actually have a vote here or not but
FWIW the rest of the proposal looked good to me.


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

[LEDE-DEV] [PATCH netifd] bridge: reset primary only after marking the member not present

2017-05-08 Thread Alex Oprea 
Run the bridge_reset_primary function only after the member being removed
has been marked as not present.
This change prevents the bridge_reset_primary function from choosing the
member being removed as the new primary member.

Signed-off-by: Alex Oprea 
---
 bridge.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bridge.c b/bridge.c
index c46d44e..96e0209 100644
--- a/bridge.c
+++ b/bridge.c
@@ -240,15 +240,15 @@ bridge_remove_member(struct bridge_member *bm)
if (!bm->present)
return;
 
-   if (bm == bst->primary_port)
-   bridge_reset_primary(bst);
-
if (bst->dev.active)
bridge_disable_member(bm);
 
bm->present = false;
bm->bst->n_present--;
 
+   if (bm == bst->primary_port)
+   bridge_reset_primary(bst);
+
if (bst->config.bridge_empty)
return;
 
-- 
2.7.4


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

Re: [LEDE-DEV] openwrt and lede - remerge proposal

2017-05-08 Thread Toke Høiland-Jørgensen 
John Crispin  writes:

> Hi,
>
> Felix, Imre and myself had 2 calls last week lasting several hours and 
> discussed
> the following proposal of conditions for a remerge that we would like to 
> propose
> and have people vote on.

Great to hear progress is being made on this! I think the proposal looks
reasonable, generally. A few comments / questions:

- What will this mean for the community rules and the release schedule?
  Will they continue from the current LEDE practices?

> - update the landing page to have the same look & feel as the current openwrt
> landing page

Well, I like the L of lede-project.org better - but it's not something
worth bikeshedding over, so meh, fine... ;)

> *) trademark/sponsorship policy
> - review/ack imres trademark policy
> - review/ack jows sponsorship policy

Links to these?

-Toke

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

Re: [LEDE-DEV] openwrt and lede - remerge proposal

2017-05-08 Thread John Crispin 



On 08/05/17 15:29, David Woodhouse wrote:

On Mon, 2017-05-08 at 15:19 +0200, John Crispin wrote:

*) mailing list
- ask david to add the openwrt-adm and openwrt lists
- announce the switch to the infradead serves, asking people to
unsubscribe if they have privacy issues with this
- import the user DB from the current openwrt and lede ML into the 2 new
mailing lists
- find out if we can redirect/auto-reply  the existing lists to the new ones

Yes, we can redirect the existing lists to the new ones — so for
example, mail sent to lede-dev will just turn up on the openwrt-dev
list instead. Assuming that's what you meant.

For importing subscribers, if that's what you want to do, I'd be
inclined to send *invitations* not just subscribe people. So each
person will get the 'someone has requested that your address be
subscribed; click here to actually do it' message. We can write our own
blurb to go out at the top of those invitations.


Hi David,

Thanks for clarifying this, sending out invites does sound reasonable.



I still haven't worked out if I actually have a vote here or not but
FWIW the rest of the proposal looked good to me.


glad that you like it.

John



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

Re: [LEDE-DEV] [OpenWrt-Devel] openwrt and lede - remerge proposal

2017-05-08 Thread Daniel Golle 
On Mon, May 08, 2017 at 09:19:42PM +0200, Zoltan HERPAI wrote:
> Hi,
> 
> On Mon, 8 May 2017, Daniel Engberg wrote:
> 
> > Trac:
> > Is it really worth keeping trac at all? What value does it add? Just
> > display a page explaining that it's shutdown and forward to OpenWrt?
> 
> There is a lot of "added value" in the tickets submitted throughout the
> years, either as comments, notes, fixes or just the issue being raised, so
> it's a good idea to keep it for archiving purposes. Older devices do die,
> but every year or so I come across shops selling brand new WRT54G (really),
> so keeping the knowledge base in an unsorted form (compared to a wiki) to
> the users can be useful. Whether that's a staticized archive or running the
> trac engine itself is another question.

I agree that there are a lot of references to dev.openwrt.org which
should remain intact. A non-interactive version would imho be
sufficient, tickets which are actually still relevant should be
re-opened on bugs.lede-project.org (which will become bugs.openwrt.org)
A grace period of 1 month starting from the notification until the
service is being shutdown (or archived read-only) would also be nice.

> 
> Other than that, I very much welcome the groundwork for the planned merge -
> thanks John, Imre and Felix for putting it together.

I agree. Thanks a lot for all the work done, this is great progress!


Cheers


Daniel

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

[LEDE-DEV] [PATCH] fritz_tffs_read: fix parsing of size argument

2017-05-08 Thread Valentin Spreckels 
The parameter specification missed that -s takes an argument.

Signed-off-by: Valentin Spreckels 

---
 package/utils/fritz-tools/src/fritz_tffs_read.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/utils/fritz-tools/src/fritz_tffs_read.c 
b/package/utils/fritz-tools/src/fritz_tffs_read.c
index f367e02..7c311a9 100644
--- a/package/utils/fritz-tools/src/fritz_tffs_read.c
+++ b/package/utils/fritz-tools/src/fritz_tffs_read.c
@@ -259,7 +259,7 @@ static void parse_options(int argc, char *argv[])
{
int c;
 
-   c = getopt(argc, argv, "abhi:ln:s");
+   c = getopt(argc, argv, "abhi:ln:s:");
if (c == -1)
break;
 
-- 
2.10.2


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

[LEDE-DEV] [PATCH] lantiq: dsl_notify: also restart pppoe interfaces

2017-05-08 Thread Valentin Spreckels 
Signed-off-by: Valentin Spreckels 

---
 target/linux/lantiq/base-files/sbin/dsl_notify.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/lantiq/base-files/sbin/dsl_notify.sh 
b/target/linux/lantiq/base-files/sbin/dsl_notify.sh
index 11ada92..8503ab4 100755
--- a/target/linux/lantiq/base-files/sbin/dsl_notify.sh
+++ b/target/linux/lantiq/base-files/sbin/dsl_notify.sh
@@ -33,7 +33,7 @@ for ifc in $interfaces; do
json_load "$(ifstatus $ifc)"
 
json_get_var proto proto
-   if [ "$proto" != "pppoa" ]; then
+   if [ "$proto" != "pppoa" -a "$proto" != "pppoe" ]; then
continue
fi
 
-- 
2.10.2


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

Re: [LEDE-DEV] openwrt and lede - remerge proposal

2017-05-08 Thread Eric Luehrsen 

Glad to hear the merge is coming and that enough issues were resolved to 
make this go forward. So ... I'll just throw my thoughts into the hopper.

 > On 05/08/2017 09:19 AM, John Crispin wrote:
>
> *) branding
>
 From a raw objective stand, OpenWrt has better market value as a brand. 
Its longer lived on the net and more unique audibly. If we surveyed 1000 
somewhat technical people, then we would have way more recognition hits. 
I realize the vote concluded already, but hopefully this thought helps 
ease some less happy minds.

 >
> *) git / github
>
This is were LEDE staging model can really shine, if you use it. Lock 
both OpenWrt and LEDE to new business for set dates. Close all 
outstanding PR in  both. Perform any "best of" merge activity in staging 
areas with core members who have time to participate. (not plebes from 
the peanut gallery like me.) Iterate on a few broken merges. Push the 
new-and-improved tree to OpenWrt. Reopen for business.

If the project will use github, then have all project components 
(netifd, procd, odhcpd/c) use github. The half-in-half-out can be 
confusing and exclude participation.

>
 > *) landing page
>
I would toss up a third possibility. Why not use the LuCI boot-strap 
theme as inspiration? The OpenWrt headline and radial from openwrt.org 
is good but the paneling could look a little more modern.

>
> *) trac
>
At some point, archive to raw text documents. No body wants to delete 
anything, but maintaining an active server-application to that end is 
just a burden.

>
> *) email accounts
>
For OpenWrt integrity, I would recommend a more assertive removal of 
personal email accounts. I realize this is contentious, but long term it 
protects OpenWrt from individuals who may attempt to misuse the brand.

>
> *) wiki / forum
>
There are long running discussions in each forum that serve as 
"documentation" in the absence of "documentation." OpenWrt wiki has a 
lot of outdated information. LEDE wiki is sparse. Closing this question 
requires a focused effort on improved documentation. Its easier to 
change if the human dependencies are not so tenuous.

>
> *) trademark/sponsorship
>
OpenWrt may generate a high value brand target in the future. Having 
seen charities and non-profits overrun by their sponsors I would simply 
urge caution. All most all sponsors have good intentions, selfish 
promotion yes, but good for the sponsored entity. It only requires one 
that doesn't and a hungry lawyer to make things difficult. Key sponsor 
concepts: non-exclusive sponsorship, limited term sponsorship, and no 
product delivery for sponsorship.

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