Discussion:
[OpenWrt-Devel] 18.03/4
John Crispin
2018-02-16 12:46:31 UTC
Permalink
Hi,

whats on the critical todo list for the upcoming release ? i still have
a few minor things that I'll be adding shortly, apart from that I am
currently not aware of any huge problems. the release will be a mix
between 4.9 and 4.14 afaik !?

    John
Philip Prindeville
2018-02-16 20:32:43 UTC
Permalink
Hi,
whats on the critical todo list for the upcoming release ? i still have a few minor things that I'll be adding shortly, apart from that I am currently not aware of any huge problems. the release will be a mix between 4.9 and 4.14 afaik !?
John
I wouldn’t mind bumping ISC-DHCP to 4.4.0 but I need someone to test it on a non-x86 platform…

The PR is sitting waiting for another tester.

https://github.com/openwrt/packages/pull/5579

And iperf3 has a pending PR to 3.4 but I don’t think that’s critical, but it might be nice to have it be tested and get in.

I’m running it (again on x86_64 hardware) but an “alien” cross-build would be better.
Philip Prindeville
2018-04-09 19:25:20 UTC
Permalink
Post by Philip Prindeville
Hi,
whats on the critical todo list for the upcoming release ? i still have a few minor things that I'll be adding shortly, apart from that I am currently not aware of any huge problems. the release will be a mix between 4.9 and 4.14 afaik !?
John
I wouldn’t mind bumping ISC-DHCP to 4.4.0 but I need someone to test it on a non-x86 platform…
The PR is sitting waiting for another tester.
https://github.com/openwrt/packages/pull/5579
And iperf3 has a pending PR to 3.4 but I don’t think that’s critical, but it might be nice to have it be tested and get in.
I’m running it (again on x86_64 hardware) but an “alien” cross-build would be better.
There was a bug in the dhcpd.init script that got fixed yesterday. It wasn’t a showstopper and only affected people doing their own explicit “list dhcp_option ‘option:xxx,yyy’” stuff.

-Philip

Rafał Miłecki
2018-02-16 20:53:58 UTC
Permalink
whats on the critical todo list for the upcoming release ? i still have a
few minor things that I'll be adding shortly, apart from that I am currently
not aware of any huge problems. the release will be a mix between 4.9 and
4.14 afaik !?
I want to switch bcm53xx to 4.14, but I'm still not sure what the
warning about overlay & tmp means. I'll paste that error message after
weekend.

Other than that I want to test blockd and see which of recent mountd
fixes apply to it as well.
--
Rafał
Hauke Mehrtens
2018-02-18 21:43:42 UTC
Permalink
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.

I did some overview of the kernel version some months ago here:
http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html

Here is the current situation as of today:

The following targets are on kernel 4.14 and are fine:
* apm821xx
* archs38
* armvirt
* cns3xxx
* malta
* mediatek
* octeon
* octeontx
* sunxi
* x86

The following targets are on kernel 4.9 and are fine:
* ar71xx
* ar7
* arc770
* at91
There are some patches for kernel 4.14 on the mailing list
waiting for response from author
* ath25
* bcm53xx
patches for 4.14 are available in master
* brcm2708
* brcm47xx
* brcm63xx
patches for 4.14 are available in master
* imx6
There are some patches for kernel 4.14 on the mailing list
which is being worked on
* ipq806x
* ixp4xx
* kirkwood
* lantiq
patches for 4.14 are in Mathias Kresin's staging tree.
* layerscape
* mpc85xx
* mvebu
patches for 4.14 are available in master
I would like to get this to kernel 4.14 by default soon.
* mxs
* omap
* orion
* pistachio
* ramips
patches for 4.14 are available in master
* rb532
* uml

The following targets are on kernel 4.4 and will probably not be
included in the next release:
* gemini
* oxnas
* zynq

The following targets are on kernel 3.18 and will probably not be
included in the next release:
* adm5120
* adm8668
* au1000
* mcs814x
I have patches which port this target to 4.4 in my tree, but
nobody tested them.
https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4
* ppc40x
* ppc44x
* xburst
I have patches which port this target to 4.4 in my tree, but
nobody tested them
https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4

This target is on kernel 4.1 (WTF):
* omap24xx

All the targets which are not on kernel 4.9 or 4.14 will probably not be
included in the next release, I also haven't seen any activity for any
of them to get support for more recent kernel versions, if you need them
please take care now.

Hauke
John Crispin
2018-02-19 06:41:47 UTC
Permalink
Post by Hauke Mehrtens
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.
http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html
* apm821xx
* archs38
* armvirt
* cns3xxx
* malta
* mediatek
* octeon
* octeontx
* sunxi
* x86
* ar71xx
* ar7
* arc770
* at91
There are some patches for kernel 4.14 on the mailing list
waiting for response from author
* ath25
* bcm53xx
patches for 4.14 are available in master
* brcm2708
* brcm47xx
* brcm63xx
patches for 4.14 are available in master
* imx6
There are some patches for kernel 4.14 on the mailing list
which is being worked on
* ipq806x
* ixp4xx
* kirkwood
* lantiq
patches for 4.14 are in Mathias Kresin's staging tree.
* layerscape
* mpc85xx
* mvebu
patches for 4.14 are available in master
I would like to get this to kernel 4.14 by default soon.
* mxs
* omap
* orion
* pistachio
* ramips
patches for 4.14 are available in master
* rb532
* uml
The following targets are on kernel 4.4 and will probably not be
* gemini
* oxnas
* zynq
The following targets are on kernel 3.18 and will probably not be
* adm5120
* adm8668
* au1000
* mcs814x
I have patches which port this target to 4.4 in my tree, but
nobody tested them.
https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4
* ppc40x
* ppc44x
* xburst
I have patches which port this target to 4.4 in my tree, but
nobody tested them
https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4
* omap24xx
All the targets which are not on kernel 4.9 or 4.14 will probably not be
included in the next release, I also haven't seen any activity for any
of them to get support for more recent kernel versions, if you need them
please take care now.
Hauke
Hi Hauke,

I planned to make that list today, thanks for taking care of it !. I
would like to see ar71xx and ramips stay on v4.9, regardless of there
being patches for v4.14. I would also like to see ar71xx never being
bumped to v4.14, I spent a few days last week revamping my old ath79
port and would like to see a hard cut, moving QCA mips target to OF only
post release.

    John
Lucian Cristian
2018-02-19 08:12:00 UTC
Permalink
Post by John Crispin
Post by Hauke Mehrtens
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.
http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html
* apm821xx
* archs38
* armvirt
* cns3xxx
* malta
* mediatek
* octeon
* octeontx
* sunxi
* x86
* ar71xx
* ar7
* arc770
* at91
    There are some patches for kernel 4.14 on the mailing list
    waiting for response from author
* ath25
* bcm53xx
    patches for 4.14 are available in master
* brcm2708
* brcm47xx
* brcm63xx
    patches for 4.14 are available in master
* imx6
    There are some patches for kernel 4.14 on the mailing list
    which is being worked on
* ipq806x
* ixp4xx
* kirkwood
* lantiq
    patches for 4.14 are in Mathias Kresin's staging tree.
* layerscape
* mpc85xx
* mvebu
    patches for 4.14 are available in master
    I would like to get this to kernel 4.14 by default soon.
* mxs
* omap
* orion
* pistachio
* ramips
    patches for 4.14 are available in master
* rb532
* uml
The following targets are on kernel 4.4 and will probably not be
* gemini
* oxnas
* zynq
The following targets are on kernel 3.18 and will probably not be
* adm5120
* adm8668
* au1000
* mcs814x
    I have patches which port this target to 4.4 in my tree, but
    nobody tested them.
    https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4
* ppc40x
* ppc44x
* xburst
    I have patches which port this target to 4.4 in my tree, but
    nobody tested them
    https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4
* omap24xx
All the targets which are not on kernel 4.9 or 4.14 will probably not be
included in the next release, I also haven't seen any activity for any
of them to get support for more recent kernel versions, if you need them
please take care now.
Hauke
Hi Hauke,
I planned to make that list today, thanks for taking care of it !. I
would like to see ar71xx and ramips stay on v4.9, regardless of there
being patches for v4.14. I would also like to see ar71xx never being
bumped to v4.14, I spent a few days last week revamping my old ath79
port and would like to see a hard cut, moving QCA mips target to OF
only post release.
    John
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Omap is working by just changing the kernel version (tested on beagle
bone black)


Regards
John Crispin
2018-02-19 08:17:38 UTC
Permalink
Post by Lucian Cristian
Post by John Crispin
Post by Hauke Mehrtens
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.
http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html
* apm821xx
* archs38
* armvirt
* cns3xxx
* malta
* mediatek
* octeon
* octeontx
* sunxi
* x86
* ar71xx
* ar7
* arc770
* at91
    There are some patches for kernel 4.14 on the mailing list
    waiting for response from author
* ath25
* bcm53xx
    patches for 4.14 are available in master
* brcm2708
* brcm47xx
* brcm63xx
    patches for 4.14 are available in master
* imx6
    There are some patches for kernel 4.14 on the mailing list
    which is being worked on
* ipq806x
* ixp4xx
* kirkwood
* lantiq
    patches for 4.14 are in Mathias Kresin's staging tree.
* layerscape
* mpc85xx
* mvebu
    patches for 4.14 are available in master
    I would like to get this to kernel 4.14 by default soon.
* mxs
* omap
* orion
* pistachio
* ramips
    patches for 4.14 are available in master
* rb532
* uml
The following targets are on kernel 4.4 and will probably not be
* gemini
* oxnas
* zynq
The following targets are on kernel 3.18 and will probably not be
* adm5120
* adm8668
* au1000
* mcs814x
    I have patches which port this target to 4.4 in my tree, but
    nobody tested them.
    https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4
* ppc40x
* ppc44x
* xburst
    I have patches which port this target to 4.4 in my tree, but
    nobody tested them
    https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4
* omap24xx
All the targets which are not on kernel 4.9 or 4.14 will probably not be
included in the next release, I also haven't seen any activity for any
of them to get support for more recent kernel versions, if you need them
please take care now.
Hauke
Hi Hauke,
I planned to make that list today, thanks for taking care of it !. I
would like to see ar71xx and ramips stay on v4.9, regardless of there
being patches for v4.14. I would also like to see ar71xx never being
bumped to v4.14, I spent a few days last week revamping my old ath79
port and would like to see a hard cut, moving QCA mips target to OF
only post release.
    John
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Omap is working by just changing the kernel version (tested on beagle
bone black)
Regards
send a patch please ...

    John
Maciej Soltysiak
2018-02-19 12:54:19 UTC
Permalink
Hi John,

As a user of an ar71xx (WNDR3800) on OpenWrt, I'd like to ask if your
desire is that ar71xx never gets bumped up to anything higher than 4.9 or
it's just not 4.14 because of some specific reasons related to 4.14?

IOW, shall I be looking for a replacement because I'll stay on 4.9 forever?

Best regards,
Maciej
Post by John Crispin
Post by Hauke Mehrtens
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.
http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html
* apm821xx
* archs38
* armvirt
* cns3xxx
* malta
* mediatek
* octeon
* octeontx
* sunxi
* x86
* ar71xx
* ar7
* arc770
* at91
There are some patches for kernel 4.14 on the mailing list
waiting for response from author
* ath25
* bcm53xx
patches for 4.14 are available in master
* brcm2708
* brcm47xx
* brcm63xx
patches for 4.14 are available in master
* imx6
There are some patches for kernel 4.14 on the mailing list
which is being worked on
* ipq806x
* ixp4xx
* kirkwood
* lantiq
patches for 4.14 are in Mathias Kresin's staging tree.
* layerscape
* mpc85xx
* mvebu
patches for 4.14 are available in master
I would like to get this to kernel 4.14 by default soon.
* mxs
* omap
* orion
* pistachio
* ramips
patches for 4.14 are available in master
* rb532
* uml
The following targets are on kernel 4.4 and will probably not be
* gemini
* oxnas
* zynq
The following targets are on kernel 3.18 and will probably not be
* adm5120
* adm8668
* au1000
* mcs814x
I have patches which port this target to 4.4 in my tree, but
nobody tested them.
https://git.lede-project.org/?p=lede/hauke/staging.git;a=sho
rtlog;h=refs/heads/kernel-4.4
* ppc40x
* ppc44x
* xburst
I have patches which port this target to 4.4 in my tree, but
nobody tested them
https://git.lede-project.org/?p=lede/hauke/staging.git;a=sho
rtlog;h=refs/heads/kernel-4.4
* omap24xx
All the targets which are not on kernel 4.9 or 4.14 will probably not be
included in the next release, I also haven't seen any activity for any
of them to get support for more recent kernel versions, if you need them
please take care now.
Hauke
Hi Hauke,
I planned to make that list today, thanks for taking care of it !. I would
like to see ar71xx and ramips stay on v4.9, regardless of there being
patches for v4.14. I would also like to see ar71xx never being bumped to
v4.14, I spent a few days last week revamping my old ath79 port and would
like to see a hard cut, moving QCA mips target to OF only post release.
John
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
John Crispin
2018-02-19 14:41:12 UTC
Permalink
Post by Maciej Soltysiak
Hi John,
As a user of an ar71xx (WNDR3800) on OpenWrt, I'd like to ask if your
desire is that ar71xx never gets bumped up to anything higher than 4.9
or it's just not 4.14 because of some specific reasons related to 4.14?
IOW, shall I be looking for a replacement because I'll stay on 4.9 forever?
Best regards,
Maciej
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.
http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html
<http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html>
* apm821xx
* archs38
* armvirt
* cns3xxx
* malta
* mediatek
* octeon
* octeontx
* sunxi
* x86
* ar71xx
* ar7
* arc770
* at91
        There are some patches for kernel 4.14 on the mailing list
        waiting for response from author
* ath25
* bcm53xx
        patches for 4.14 are available in master
* brcm2708
* brcm47xx
* brcm63xx
        patches for 4.14 are available in master
* imx6
        There are some patches for kernel 4.14 on the mailing list
        which is being worked on
* ipq806x
* ixp4xx
* kirkwood
* lantiq
        patches for 4.14 are in Mathias Kresin's staging tree.
* layerscape
* mpc85xx
* mvebu
        patches for 4.14 are available in master
        I would like to get this to kernel 4.14 by default soon.
* mxs
* omap
* orion
* pistachio
* ramips
        patches for 4.14 are available in master
* rb532
* uml
The following targets are on kernel 4.4 and will probably not be
* gemini
* oxnas
* zynq
The following targets are on kernel 3.18 and will probably not be
* adm5120
* adm8668
* au1000
* mcs814x
        I have patches which port this target to 4.4 in my
tree, but
        nobody tested them.
https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4
<https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4>
* ppc40x
* ppc44x
* xburst
        I have patches which port this target to 4.4 in my
tree, but
        nobody tested them
https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4
<https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4>
* omap24xx
All the targets which are not on kernel 4.9 or 4.14 will probably not be
included in the next release, I also haven't seen any activity for any
of them to get support for more recent kernel versions, if you need them
please take care now.
Hauke
Hi Hauke,
I planned to make that list today, thanks for taking care of it !.
I would like to see ar71xx and ramips stay on v4.9, regardless of
there being patches for v4.14. I would also like to see ar71xx
never being bumped to v4.14, I spent a few days last week
revamping my old ath79 port and would like to see a hard cut,
moving QCA mips target to OF only post release.
    John
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
<https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>
Hi Maciej

please dont top post.

ath79 is the same as ar71xx but uses dts files instead of mach files

    John
Maciej Soltysiak
2018-02-19 15:39:01 UTC
Permalink
Post by John Crispin
please dont top post.
Apologies! Thank you for the kind reminder.
Post by John Crispin
ath79 is the same as ar71xx but uses dts files instead of mach files
Right, does that mean there might be an ath79 target, which is not
ready yet, or am I confusing things?
Post by John Crispin
John
Maciej
Karl Palsson
2018-02-19 10:42:02 UTC
Permalink
Post by Hauke Mehrtens
The following targets are on kernel 4.4 and will probably not
* gemini
This is a platform that upstream seems to be actually working on,
would it not be at least polite to keep it alive while it's
landing in mainline? I don't have any hardware or care myself, it
just seems odd to kill the one that's being worked on.

Cheers,
Karl P
Michael Heimpold
2018-02-19 14:59:03 UTC
Permalink
Hi,
...
...
* mxs
...
a few weeks ago, I was in contact with Zoltan who started working
on 4.14 support for mxs. I found some patches in his staging repo
and added some patches on top.
I've pushed this in a Github branch:
https://github.com/mhei/source/tree/mxs-4.14

I run tested this on both I2SE Duckbill devices and Olimex OLinuXino
Maxi boards - no obvious problems so far, so I think we can go ahead
for this platform with 4.14.

Regards,
Michael
Zoltan HERPAI
2018-02-20 14:20:49 UTC
Permalink
Hi,
Post by Michael Heimpold
Hi,
...
...
* mxs
...
a few weeks ago, I was in contact with Zoltan who started working
on 4.14 support for mxs. I found some patches in his staging repo
and added some patches on top.
https://github.com/mhei/source/tree/mxs-4.14
I run tested this on both I2SE Duckbill devices and Olimex OLinuXino
Maxi boards - no obvious problems so far, so I think we can go ahead
for this platform with 4.14.
Thanks Michael, this is pushed to master now.

Regards,
Zoltan H
Hauke Mehrtens
2018-04-01 14:48:52 UTC
Permalink
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.

I did some overview of the kernel version some months ago here:
http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html
http://lists.infradead.org/pipermail/lede-dev/2018-February/011308.html

Here is the current situation as of today:


The following targets are on kernel 4.14 and are fine:
* apm821xx
* archs38
* armvirt
* bcm53xx
* cns3xxx
* imx6
* ipq40xx
* kirkwood
* malta
* mediatek
* mvebu
* mxs
* octeon
* octeontx
* pistachio
* sunxi
* x86


The following targets are on kernel 4.9 and are fine:
* ar71xx
* ar7
* arc770
* at91
There are some patches for kernel 4.14 on the mailing list,
but it looks like nobody with the hardware wants to take care
of them.
* ath25
* brcm2708
* brcm47xx
There is a pull request with kernel 4.14 patches on github, we
will probably stay with kernel 4.9 for the next release.
* brcm63xx
patches for 4.14 are available in master
* ipq806x
* ixp4xx
* lantiq
patches for 4.14 are available in master, we will probably stay
with kernel 4.9 for the next release.
* layerscape
* mpc85xx
* omap
There is a pull request with kernel 4.14 patches on github.
* orion
* ramips
patches for 4.14 are available in master, we will probably stay
with kernel 4.9 for the next release.
* rb532
* uml


The following targets are on kernel 4.4 and will probably not be
included in the next release:
* gemini
There are patches for kernel 4.14 on the mailing list, we will
probably get them in before the release and ship this with 4.14
* oxnas
* zynq

The following targets are on kernel 3.18 and will probably not be
included in the next release:
* adm5120
* adm8668
* au1000
* mcs814x
* ppc40x
* ppc44x
* xburst


This target is on kernel 4.1 (WTF):
* omap24xx


All the targets which are not on kernel 4.9 or 4.14 will probably not be
included in the next release, I also haven't seen any activity for any
of them expected the gemini target to get support for more recent kernel
versions, if you need them please take care now.

I am fine with the current status and do not see this as a blocker for
the next release, all important targets are on either 4.9 or 4.14, if
someone wants to see his target on a more recent version we are still
open for patches.

Hauke
Alexandru Ardelean
2018-04-01 17:37:05 UTC
Permalink
Post by Hauke Mehrtens
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.
http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html
http://lists.infradead.org/pipermail/lede-dev/2018-February/011308.html
* apm821xx
* archs38
* armvirt
* bcm53xx
* cns3xxx
* imx6
* ipq40xx
* kirkwood
* malta
* mediatek
* mvebu
* mxs
* octeon
* octeontx
* pistachio
* sunxi
* x86
* ar71xx
* ar7
* arc770
* at91
There are some patches for kernel 4.14 on the mailing list,
but it looks like nobody with the hardware wants to take care
of them.
* ath25
* brcm2708
* brcm47xx
There is a pull request with kernel 4.14 patches on github, we
will probably stay with kernel 4.9 for the next release.
* brcm63xx
patches for 4.14 are available in master
* ipq806x
* ixp4xx
* lantiq
patches for 4.14 are available in master, we will probably stay
with kernel 4.9 for the next release.
* layerscape
* mpc85xx
* omap
There is a pull request with kernel 4.14 patches on github.
* orion
* ramips
patches for 4.14 are available in master, we will probably stay
with kernel 4.9 for the next release.
* rb532
* uml
The following targets are on kernel 4.4 and will probably not be
* gemini
There are patches for kernel 4.14 on the mailing list, we will
probably get them in before the release and ship this with 4.14
* oxnas
* zynq
Will these targets be dropped/removed from the tree ?
I'd be interested in upgrading the zynq target.
And I also have a partial work/effort in a repo, but not enough time
to test + push it.

I don't need this to be part of the 18.xx release, just curios if it
will still be in the tree, and then I can alloc time for it at a later
time.

Thanks
Alex
Post by Hauke Mehrtens
The following targets are on kernel 3.18 and will probably not be
* adm5120
* adm8668
* au1000
* mcs814x
* ppc40x
* ppc44x
* xburst
* omap24xx
All the targets which are not on kernel 4.9 or 4.14 will probably not be
included in the next release, I also haven't seen any activity for any
of them expected the gemini target to get support for more recent kernel
versions, if you need them please take care now.
I am fine with the current status and do not see this as a blocker for
the next release, all important targets are on either 4.9 or 4.14, if
someone wants to see his target on a more recent version we are still
open for patches.
Hauke
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Roman Yeryomin
2018-04-09 10:48:44 UTC
Permalink
Post by Hauke Mehrtens
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.
The following targets are on kernel 4.4 and will probably not be
* gemini
There are patches for kernel 4.14 on the mailing list, we will
probably get them in before the release and ship this with 4.14
Hi Hauke, I have a working 4.9, is it too late to submit?
I'll also work on 4.14 submitted by Linus, but it didn't work out of the
box, so probably will take more time.

Regards,
Roman
Hauke Mehrtens
2018-03-04 15:15:08 UTC
Permalink
Post by John Crispin
Hi,
whats on the critical todo list for the upcoming release ? i still have
a few minor things that I'll be adding shortly, apart from that I am
currently not aware of any huge problems. the release will be a mix
between 4.9 and 4.14 afaik !?
I think the kernel situation is ok now and not blocking a release, we
will have a mixed kernel 4.9 and 4.14 release. All important targets are
on one of these two kernel versions by now.
The patches for the gemini target will probably get included soon.
Some targets will probably be updated from 4.9 to 4.14, but this is not
blocking.


What do we want to do with GCC 5.5 versus 7.3?
GCC 5.5 is getting old, we have multiple problems with it, the big
blocker for GCC 7 was just fixed upstream and we backported that fix.
see: http://git.openwrt.org/25aaff9100065dba881be71b9dcab1e9cc8a7b5f
The x86 and x86_64 architectures are already on GCC 7.3, the ARC
architecture uses their own GCC fork based on version 7.X all other
architectures are on GCC 5.5.

We have the following problems with GCC 5.5:
* U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64
* GCC 5 and older are producing too big binaries, e.g. the SPL on the
Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot
2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem.
* busybox on the gemini target updated to kernel 4.14 does not work
correctly.
* GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has
the retpoline fixes against Spectre included

As the x86 target use GCC 7.3 now, there are multiple pull requests
fixing some build problems in some packages with GCC 7.
I am not aware of any regressions in GCC 7 compared to GCC 5.
Changing the default compiler from GCC 5 to GCC 7 is no big problem, the
problems are the regressions we are not aware of by now, if we change
the default compiler for all architectures to GCC 7 we should probably
wait 4 weeks before doing an RC release to be sure most of the runtime
problems with GCC 7 are found.

If we do the switch to GCC 7 I think we should also change binutils from
2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which
was already fixed in 2.28.1:
https://git.openwrt.org/bcd17ce9a3308accc30d99f4dd43f2062bb3fabc
The minor versions contains more bugfixes.


There is also a pull request for busybox 2.28.1 at github, this will
probably also introduce some more regressions, so I am not sure if we
should take it before or after the release.
https://github.com/openwrt/openwrt/pull/733
I do not have a real opinion on this and I am probably the wrong person
to judge this.


I do not know what the status of the software fast path patches are, but
they are looking interesting.


My proposal would be to update all targets to GCC 7.3 and also use
binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
possible and then we branch of end of March or beginning of April for
18.X and do a RC1 one week after creating the branch.

Hauke
Felix Fietkau
2018-03-04 15:40:38 UTC
Permalink
Post by Hauke Mehrtens
There is also a pull request for busybox 2.28.1 at github, this will
probably also introduce some more regressions, so I am not sure if we
should take it before or after the release.
https://github.com/openwrt/openwrt/pull/733
I do not have a real opinion on this and I am probably the wrong person
to judge this.
Anything useful in there?
Post by Hauke Mehrtens
I do not know what the status of the software fast path patches are, but
they are looking interesting.
I think the flow offload support will be ready soon. So far it's looking
good aside from some issues with TCP connection timeout handling that
I'm going to deal with soon. We should make it clear that those patches
are still experimental though.
Post by Hauke Mehrtens
My proposal would be to update all targets to GCC 7.3 and also use
binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
possible and then we branch of end of March or beginning of April for
18.X and do a RC1 one week after creating the branch.
Fine with me. I'll run some more test builds for various architectures.

- Felix
Hauke Mehrtens
2018-03-04 15:53:55 UTC
Permalink
Post by Felix Fietkau
Post by Hauke Mehrtens
There is also a pull request for busybox 2.28.1 at github, this will
probably also introduce some more regressions, so I am not sure if we
should take it before or after the release.
https://github.com/openwrt/openwrt/pull/733
I do not have a real opinion on this and I am probably the wrong person
to judge this.
Anything useful in there?
I haven't seen there anything useful, except support for some new MIPS
ISAs, but I do not know if they ever will be relevant.
binutils:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/tags/binutils-2_30
gas:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gas/NEWS;hb=refs/tags/binutils-2_30
ld:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/tags/binutils-2_30
Post by Felix Fietkau
Post by Hauke Mehrtens
I do not know what the status of the software fast path patches are, but
they are looking interesting.
I think the flow offload support will be ready soon. So far it's looking
good aside from some issues with TCP connection timeout handling that
I'm going to deal with soon. We should make it clear that those patches
are still experimental though.
Post by Hauke Mehrtens
My proposal would be to update all targets to GCC 7.3 and also use
binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
possible and then we branch of end of March or beginning of April for
18.X and do a RC1 one week after creating the branch.
Fine with me. I'll run some more test builds for various architectures.
Hauke
Karl Palsson
2018-03-04 21:19:16 UTC
Permalink
Post by Felix Fietkau
Post by Hauke Mehrtens
There is also a pull request for busybox 2.28.1 at github, this will
probably also introduce some more regressions, so I am not sure if we
should take it before or after the release.
https://github.com/openwrt/openwrt/pull/733
I do not have a real opinion on this and I am probably the wrong person
to judge this.
Anything useful in there?
Actually getting NTP resolution if you have any unreachable
addresses listed? (ok, doesn't happen for everyone) NTP is _far_
more resilient in the face of problems with upstreams than it was
in 1.27 and 1.26. 1.25 worked well, but for different reasons :)
Lucian Cristian
2018-03-07 17:49:26 UTC
Permalink
Post by Hauke Mehrtens
Post by John Crispin
Hi,
whats on the critical todo list for the upcoming release ? i still have
a few minor things that I'll be adding shortly, apart from that I am
currently not aware of any huge problems. the release will be a mix
between 4.9 and 4.14 afaik !?
I think the kernel situation is ok now and not blocking a release, we
will have a mixed kernel 4.9 and 4.14 release. All important targets are
on one of these two kernel versions by now.
The patches for the gemini target will probably get included soon.
Some targets will probably be updated from 4.9 to 4.14, but this is not
blocking.
What do we want to do with GCC 5.5 versus 7.3?
GCC 5.5 is getting old, we have multiple problems with it, the big
blocker for GCC 7 was just fixed upstream and we backported that fix.
see: http://git.openwrt.org/25aaff9100065dba881be71b9dcab1e9cc8a7b5f
The x86 and x86_64 architectures are already on GCC 7.3, the ARC
architecture uses their own GCC fork based on version 7.X all other
architectures are on GCC 5.5.
* U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64
* GCC 5 and older are producing too big binaries, e.g. the SPL on the
Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot
2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem.
* busybox on the gemini target updated to kernel 4.14 does not work
correctly.
* GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has
the retpoline fixes against Spectre included
As the x86 target use GCC 7.3 now, there are multiple pull requests
fixing some build problems in some packages with GCC 7.
I am not aware of any regressions in GCC 7 compared to GCC 5.
Changing the default compiler from GCC 5 to GCC 7 is no big problem, the
problems are the regressions we are not aware of by now, if we change
the default compiler for all architectures to GCC 7 we should probably
wait 4 weeks before doing an RC release to be sure most of the runtime
problems with GCC 7 are found.
If we do the switch to GCC 7 I think we should also change binutils from
2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which
https://git.openwrt.org/bcd17ce9a3308accc30d99f4dd43f2062bb3fabc
The minor versions contains more bugfixes.
There is also a pull request for busybox 2.28.1 at github, this will
probably also introduce some more regressions, so I am not sure if we
should take it before or after the release.
https://github.com/openwrt/openwrt/pull/733
I do not have a real opinion on this and I am probably the wrong person
to judge this.
I do not know what the status of the software fast path patches are, but
they are looking interesting.
My proposal would be to update all targets to GCC 7.3 and also use
binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
possible and then we branch of end of March or beginning of April for
18.X and do a RC1 one week after creating the branch.
Hauke
_______________________________________________
Lede-dev mailing list
http://lists.infradead.org/mailman/listinfo/lede-dev
testing r6395-6c194078db on a ramips Ralink RT5350 with 4.14 and GCC 7.3
gives this error in luci

daemon.err uhttpd[873]: /usr/bin/lua: /usr/lib/lua/luci/debug.lua:6:
attempt to call a number value
daemon.err uhttpd[873]: stack traceback:
daemon.err uhttpd[873]:        /usr/lib/lua/luci/debug.lua:6: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]:        /usr/lib/lua/luci/util.lua:8: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]:        /usr/lib/lua/luci/config.lua:4: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]: /usr/lib/lua/luci/cacheloader.lua:5: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]:        /www/cgi-bin/luci:2: in main chunk
daemon.err uhttpd[873]:        [C]: ?


Regards
Matthias Schiffer
2018-03-09 12:56:56 UTC
Permalink
Post by Lucian Cristian
testing r6395-6c194078db on a ramips Ralink RT5350 with 4.14 and GCC 7.3
gives this error in luci
attempt to call a number value
daemon.err uhttpd[873]:        /usr/lib/lua/luci/debug.lua:6: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]:        /usr/lib/lua/luci/util.lua:8: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]:        /usr/lib/lua/luci/config.lua:4: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]: /usr/lib/lua/luci/cacheloader.lua:5: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]:        /www/cgi-bin/luci:2: in main chunk
daemon.err uhttpd[873]:        [C]: ?
s = 'foo'
print(s:sub(2))
fails, while
Post by Lucian Cristian
print(s.sub(s, 2))
works correctly, even though the former is only syntactic sugar for the
latter. FWIW, type(s) correctly states that s is a string. Looking into it now.

Matthias
Matthias Schiffer
2018-03-09 19:43:26 UTC
Permalink
Post by Matthias Schiffer
Post by Lucian Cristian
testing r6395-6c194078db on a ramips Ralink RT5350 with 4.14 and GCC 7.3
gives this error in luci
attempt to call a number value
daemon.err uhttpd[873]:        /usr/lib/lua/luci/debug.lua:6: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]:        /usr/lib/lua/luci/util.lua:8: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]:        /usr/lib/lua/luci/config.lua:4: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]: /usr/lib/lua/luci/cacheloader.lua:5: in main chunk
daemon.err uhttpd[873]:        [C]: in function 'require'
daemon.err uhttpd[873]:        /www/cgi-bin/luci:2: in main chunk
daemon.err uhttpd[873]:        [C]: ?
s = 'foo'
print(s:sub(2))
fails, while
Post by Lucian Cristian
print(s.sub(s, 2))
works correctly, even though the former is only syntactic sugar for the
latter. FWIW, type(s) correctly states that s is a string. Looking into it now.
Matthias
Bug reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790

Matthias
Alif M. Ahmad
2018-03-05 01:26:02 UTC
Permalink
Post by John Crispin
Hi,
whats on the critical todo list for the upcoming release ? i still have
a few minor things that I'll be adding shortly, apart from that I am
currently not aware of any huge problems. the release will be a mix
between 4.9 and 4.14 afaik !?
    John
I would like to have uefi-gpt image for x86_64. For this feature, uefi
related changes on Jow's staging repository should be merged.

I have fixed kernel panic issue when booting gpt image on bios based
systems with my previous patch series.
Philip Prindeville
2018-03-10 01:01:14 UTC
Permalink
Post by Alif M. Ahmad
Post by John Crispin
Hi,
whats on the critical todo list for the upcoming release ? i still have
a few minor things that I'll be adding shortly, apart from that I am
currently not aware of any huge problems. the release will be a mix
between 4.9 and 4.14 afaik !?
John
I would like to have uefi-gpt image for x86_64. For this feature, uefi
related changes on Jow's staging repository should be merged.
I have fixed kernel panic issue when booting gpt image on bios based
systems with my previous patch series.
There’s also the packaging issue of combining the target and host packaging of sgdisk.

Jo: did you have any time to look at that?

-Philip
Hauke Mehrtens
2018-04-01 15:38:06 UTC
Permalink
Post by John Crispin
Hi,
whats on the critical todo list for the upcoming release ? i still have
a few minor things that I'll be adding shortly, apart from that I am
currently not aware of any huge problems. the release will be a mix
between 4.9 and 4.14 afaik !?
Hi,

For me the current status of master looks good.

1. All important targets are either on kernel 4.9 or 4.14, the rest will
probably get removed.

2. We did the move to GCC 7.3 and binutils 2.29.1 and this went pretty
well, I am only aware of one problem with perl on the apm821xx (powerpc)
target https://bugs.openwrt.org/index.php?do=details&task_id=1464 which
is related to the GCC update and which is not fixed.

3. The update to busybox 1.28.2 is still open, but this was already
tested by many people. I am fine with merging it if it will be done soon.

There are probably a lot of small things but nothing big any more in my
opinion, I do not see any release blockers for now and would like to
start with the 18.X release soon.

Are there any problems still know which would block a release?

I would propose this timeline:
1. Branch of openwrt-18.05 at 7. April
2. Create openwrt-18.05-rc1 release on 14. April
3. Create openwrt-18.05-rc2 release on 28. April
4. Create openwrt-18.05 final release on 12. Mai
If we find more problems this will be extended.

@Jow Do you have time to prepare the build bots for this?
Do others have some time in April to manage this release and take care
about bug reports?
I haven't done a release yet and probably need some help.

Hauke
Loading...