Re: [LEDE-DEV] [PATCH] kernel: Add kmod-ethoc

[John Crispin]

On 23/12/2016 03:47, Florian Fainelli wrote:
> Le 12/08/16 à 23:05, John Crispin a écrit :
>>
>>
>> On 09/12/2016 04:31, Florian Fainelli wrote:
>>> Add the kernel module package for the Opencores.org Ethernet MAC,
>>> depends on PHYLIB.
>>>
>>> Signed-off-by: Florian Fainelli 
>>> ---
>>>  package/kernel/linux/modules/netdevices.mk | 15 +++
>>>  1 file changed, 15 insertions(+)
>>>
>>> diff --git a/package/kernel/linux/modules/netdevices.mk 
>>> b/package/kernel/linux/modules/netdevices.mk
>>> index 787dd40efc9a..e8d80aeefc2c 100644
>>> --- a/package/kernel/linux/modules/netdevices.mk
>>> +++ b/package/kernel/linux/modules/netdevices.mk
>>> @@ -886,3 +886,18 @@ define KernelPackage/spi-ks8995/description
>>>  endef
>>>  
>>>  $(eval $(call KernelPackage,spi-ks8995))
>>
>> minor nitpick, all the *.mk files have 2 blank lines between
>> KernelPackage templates. i've added the missing blank line and merged
>> the patch to my staging tree
> 
> Did you? Can't find it:
> 
> git log blogic/master --grep="ethoc"
> 

apparently i forgot, will merge it just now, sorry about that.

John

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

Re: [LEDE-DEV] Release planning

[John Crispin]

On 22/12/2016 21:59, Rich Brown wrote:
> Is it too soon to begin identifying/enumerating the features/packages that 
> will go into the 17.01 release? Thanks.
> 
> Rich

if you would do that it'd be amazing. i recall doing it myself for the
last 2 releases and it is actually a huge pile of work. starting early
is good and will safe us headaches in the later phases of the release.

John

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

Re: [LEDE-DEV] [PATCH] kernel: Add kmod-ethoc

[Florian Fainelli]

Le 12/08/16 à 23:05, John Crispin a écrit :
> 
> 
> On 09/12/2016 04:31, Florian Fainelli wrote:
>> Add the kernel module package for the Opencores.org Ethernet MAC,
>> depends on PHYLIB.
>>
>> Signed-off-by: Florian Fainelli 
>> ---
>>  package/kernel/linux/modules/netdevices.mk | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/package/kernel/linux/modules/netdevices.mk 
>> b/package/kernel/linux/modules/netdevices.mk
>> index 787dd40efc9a..e8d80aeefc2c 100644
>> --- a/package/kernel/linux/modules/netdevices.mk
>> +++ b/package/kernel/linux/modules/netdevices.mk
>> @@ -886,3 +886,18 @@ define KernelPackage/spi-ks8995/description
>>  endef
>>  
>>  $(eval $(call KernelPackage,spi-ks8995))
> 
> minor nitpick, all the *.mk files have 2 blank lines between
> KernelPackage templates. i've added the missing blank line and merged
> the patch to my staging tree

Did you? Can't find it:

git log blogic/master --grep="ethoc"
-- 
Florian

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

Re: [LEDE-DEV] [OpenWrt-Devel] [OpenWrt-Users] Talks between OpenWrt and LEDE

[Russell Senior]

> "John" == John Crispin  writes:

>> IMHO if you want to add "freshness" and still leverage the old brand
>> you do something like, e.g., Pepsi Zero.  You do "The OpenWRT LEDE
>> Edition!".
>> 
>> Just a thought.
>> 

John> certainly an interesting idea worth considering.

FWIW, when our CWN was considering a rebranding (we still are, on the
back burner), the advice we got was to phase in name changes over time
scales of a year or so, with co-branding during the transition, very
gradually increasing emphasis on the new name and decreasing emphasis on
the old name.

All names have upsides and downsides.


-- 
Russell Senior, President
russ...@personaltelco.net

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

Re: [LEDE-DEV] Release planning

[David Lang]

On Thu, 22 Dec 2016, Rich Brown wrote:


Is it too soon to begin identifying/enumerating the features/packages that will 
go into the 17.01 release? Thanks.


nope, you can start going through the git log history to pick out things that 
you think should be highlighted now. Even if the release doesn't happen for a 
while, the list will still be useful as it reduces how far back people would 
have to go at the point of release.


David Lang

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

Re: [LEDE-DEV] Release planning

[Rich Brown]

Is it too soon to begin identifying/enumerating the features/packages that will 
go into the 17.01 release? Thanks.

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[James Feeney]

On 12/22/2016 12:27 AM, John Crispin wrote:
> or do we want to build a "one stop shop" for embedded linux

Yes, we do?

When I read that, my gut reaction was "Oh yeah - embedded linux."

I remember, when I first heard about "LEDE", as distinct from OpenWRT, I was
attracted to the broader focus on "embedded linux", in contrast to the "wireless
router" focus implied by "OpenWRT".  That promise of embedded device support is
still my mental rationalization for choosing LEDE over OpenWRT.

There is something to be said for the "evolved" branding of the LEDE name.  How
important is this focus on "embedded linux", which implies a linux distribution
that runs, additionally, on devices that are *not* wireless routers?  There are
a great number of single-board computers that exist now that did not exist when
OpenWRT was first released in 2004.

The original WRT54G was first released in December 2002.
The first generation (Raspberry Pi 1 Model B) was released in February 2012.

Consider:
https://en.wikipedia.org/wiki/Comparison_of_single-board_computers

Does LEDE have builds for all of these products?


I imagine that the stable/bleeding-edge issue might be addressed in the same way
as other projects which have designated "long term support" versions.


Just for fun:
https://en.wiktionary.org/wiki/lede

James

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

[LEDE-DEV] [PATCH] libubox: replace strtok with _r version.

[Rosen Penev]

_r is re-entrant. Also happens to silence a cppcheck warning.

Signed-off by: Rosen Penev 
---
 ulog.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ulog.c b/ulog.c
index 296605d..b7300e7 100644
--- a/ulog.c
+++ b/ulog.c
@@ -35,12 +35,13 @@ static const char *ulog_default_ident(void)
FILE *self;
static char line[64];
char *p = NULL;
+   char *sbuf;
 
if ((self = fopen("/proc/self/status", "r")) != NULL) {
while (fgets(line, sizeof(line), self)) {
if (!strncmp(line, "Name:", 5)) {
-   strtok(line, "\t\n");
-   p = strtok(NULL, "\t\n");
+   strtok_r(line, "\t\n", );
+   p = strtok_r(NULL, "\t\n", );
break;
}
}
-- 
2.9.3


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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[John Crispin]

On 22/12/2016 19:57, Giuseppe Lippolis wrote:
 we did propose this as an idea, keep lede as the bleeding edge tree
 and
>>> use
 openwrt as the stable release tree with long term support. the
 openwrt
>>> folks
 made it a condition for the merger that this may not be the case. i
 think
>>> the
 sentence used by the owrt folks was "merge to one project/tree or
 dont merge"
>>>
>>> This sentence doesn't sound very constructive. Anyhow:
>>
>> sorry if you feel that way, i am trying to be constructive and inclusive
> to the
>> best of my ability. just because i am nosy, why do you think this is not
>> constructive ?
> 
> John, my criticism was for the people saying: "merge to one project/tree or
> don't merge".
> Not for you!
> 
> Bye.
> 

ah ok, makes sense now, thanks for elaborating, i was a little suprised :-)

John

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[Giuseppe Lippolis]

> >> we did propose this as an idea, keep lede as the bleeding edge tree
> >> and
> > use
> >> openwrt as the stable release tree with long term support. the
> >> openwrt
> > folks
> >> made it a condition for the merger that this may not be the case. i
> >> think
> > the
> >> sentence used by the owrt folks was "merge to one project/tree or
> >> dont merge"
> >
> > This sentence doesn't sound very constructive. Anyhow:
> 
> sorry if you feel that way, i am trying to be constructive and inclusive
to the
> best of my ability. just because i am nosy, why do you think this is not
> constructive ?

John, my criticism was for the people saying: "merge to one project/tree or
don't merge".
Not for you!

Bye.


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

Re: [LEDE-DEV] [OpenWrt-Users] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[John Crispin]

On 22/12/2016 16:57, Karl O. Pinc wrote:
> On Thu, 22 Dec 2016 00:58:22 -0800 (PST)
> David Lang  wrote:
> 
>> On Thu, 22 Dec 2016, John Crispin wrote:
> 
>>> claiming that there is only one option and no alternatives is just
>>> not constructive and wont lead to a broad discussion during which
>>> we can find a consensus.  
>>
>> sorry, I did not mean to imply there is only one option.
> 
> IMHO if you want to add "freshness" and still leverage the
> old brand you do something like, e.g., Pepsi Zero.  You do
> "The OpenWRT LEDE Edition!".
> 
> Just a thought.
> 

certainly an interesting idea worth considering.

John

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

Re: [LEDE-DEV] Reproducible builds & feeds

[Holger Levsen]

Hi,

thanks for your mail Rafał and I'm very sorry for the late reply…

On Sat, Oct 15, 2016 at 05:32:02PM +0200, Rafał Miłecki wrote:
> After Holger & Alexander talk at OpenWrt Summit I started thinking
> about handling feeds in LEDE. Right now we simply point to external
> repositories within feeds.conf(.default):
> src-git packages https://git.lede-project.org/feed/packages.git
> src-git luci https://git.lede-project.org/project/luci.git
> src-git routing https://git.lede-project.org/feed/routing.git
> src-git telephony https://git.lede-project.org/feed/telephony.git
> 
> I see few problems with this solution:
> 
> 1) No info on used feeds revisions
> Problem: When you get an image you can't say which revisions of feeds
> were used to build it.

agreed.

> Possible solution: Include some extra file with info about each feed
> and used revision
> 
> 2) No pointing specific revision
> Problem: We always use the latest revision of each feed. It's easy to
> hit some problem/regression introduced in a feed without an easy way
> of tracking it down. You have to guess which was the latest working
> revision.

agreed.

> Possible solution: Always point specific revision in
> feeds.conf.default, e.g. src-git packages
> https://git.lede-project.org/feed/packages.git^commithash .
> Unfortunately this will require us to update this file over and over.
> 
> 3) The way of specifying revisions
> Problem: This is only possible with manually creating a proper
> feeds.conf. I'm wondering if this would make sense to make is somehow
> more script friendly? Alexander, Holger: what do you think about this?

use git tags?

> Possible solution: Implement solution suggested in problem 2 or maybe
> add support for some env variable(s) pointing revision(s)?
> 
> I think the problem that really needs solving is the first one. The
> rest we can probably just discuss (hint: waiting for your opinions).
> Right now it's not possible/easy to rebuild image I got downloaded.
> Even if I'm ready to create my own feeds.conf I don't know what
> revisions to put there. Also please note this is only an introduction
> to have binary reproducible builds.

and now I will also say: sorry for the lame reply too, or in other
words: yes, I agree these problems should be solved, however i'm not
much familar with openwrt/lede internals, I basically just know that you
have these package feeds.

btw, I will be at 33c3 and happy to discuss anything related to
reproducible builds there. Either grab me if you see me or send an mail
so we can agree on a meeting time+date.


-- 
cheers,
Holger


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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[Giuseppe Lippolis]

> > When I decided where to port my contribution I considered the "focus 
> > on stability and functionality" more interesting than the "bleeding 
> > edge functionality", therefore I selected LEDE.
> > Now I understand that a merge is ongoing.
> > Can I ask to the people taking care about the merge how the 
> > trade-off between stability and bleeding edge is solved?
> 
> we did propose this as an idea, keep lede as the bleeding edge tree 
> and
use
> openwrt as the stable release tree with long term support. the openwrt
folks
> made it a condition for the merger that this may not be the case. i 
> think
the
> sentence used by the owrt folks was "merge to one project/tree or dont 
> merge"

This sentence doesn't sound very constructive. Anyhow:
I'm sure that the owrt folks have good reason to merge, It is a question of
transparencies, can they share with us these reasons?
And most important, what are they proposing to trade-off between stability
and bleeding edge?

In my opinion a conflict unsolved is simple an unsolved conflict. 
If the merge means restore the status before the split, the probability to
have a new split is high.
 
Therefore in absence of valid proposal  to trade-off, my advice is to
identify the perimeter where really make sense to merge and on the top of
this common base built two different project, one focused on the "stability"
and the second on the "bleeding edge".

> > At the end the market share will answer if a single product make 
> > sense or not.

Anyhow on this point I hope that the discussion can be transparent and
extended to the community.

Bye,
Giuseppe.


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

Re: [LEDE-DEV] [PATCH] musl: backport various post-1.1.15 fixes

[Felix Fietkau]

On 2016-12-22 16:36, Koen Vandeputte wrote:
> 
> On 2016-12-22 16:27, Felix Fietkau wrote:
>> I think we should probably just update musl to current git instead, and
>> avoid carrying so many patches.
>>
>> - Felix
>>
> 
> 
> Hi Felix,
> 
> This patch was born out of the discussion below:
> 
> Besides the method being used (patches vs HEAD bump),
> what is your opinion on adding these fixes close to branch-day?
I'm fine with adding those fixes.

- Felix


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

[LEDE-DEV] [PATCH v2 3/3] musl: refresh patches

[Koen Vandeputte]

Signed-off-by: Koen Vandeputte 
---
 toolchain/musl/patches/300-relative.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/toolchain/musl/patches/300-relative.patch 
b/toolchain/musl/patches/300-relative.patch
index e34e60a..6e30e0a 100644
--- a/toolchain/musl/patches/300-relative.patch
+++ b/toolchain/musl/patches/300-relative.patch
@@ -1,6 +1,6 @@
 --- a/Makefile
 +++ b/Makefile
-@@ -215,7 +215,7 @@ $(DESTDIR)$(includedir)/%: $(srcdir)/inc
+@@ -221,7 +221,7 @@ $(DESTDIR)$(includedir)/%: $(srcdir)/inc
$(INSTALL) -D -m 644 $< $@
  
  $(DESTDIR)$(LDSO_PATHNAME): $(DESTDIR)$(libdir)/libc.so
-- 
2.7.4


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

[LEDE-DEV] [PATCH v2 2/3] musl: backport various post-1.1.15 fixes

[Koen Vandeputte]

Backport most important fixes up to latest HEAD

- Taken post-commit reverts/fixes into account

Compile tested
Run-tested on cns3xxx & imx6 targets

Signed-off-by: Koen Vandeputte 
---
 ...ime-day-month-names-not-to-vary-by-locale.patch |  41 +++
 ...d-pwrite-syscall-calling-convention-on-sh.patch |  71 
 ...ttyname-refers-to-the-same-file-as-the-fd.patch |  49 +++
 .../025-fix-ffsync-by-changing-it-to-osync.patch   |  25 ++
 ...-alt-form-octal-zero-flag-and-field-width.patch |  31 ++
 ...-ifru_data-and-ifcu_buf-types-in-net-if.h.patch |  35 ++
 .../030-fix-if_indextoname-error-case.patch|  36 ++
 ...and-wcsftime_l-prototypes-to-wchar-header.patch |  38 ++
 ...fined-behavior-in-sched.h-cpu_set_t-usage.patch |  43 +++
 ...getservby_r-result-pointer-value-on-error.patch |  41 +++
 .../036-fix-strftime-y-for-negative-tm_year.patch  |  23 ++
 ...hecks-in-regexec-buffer-size-computations.patch |  72 
 ...with-haystack-strings-longer-than-int_max.patch | 189 ++
 ...float-printf-needed-precision-computation.patch |  35 ++
 ...ows-and-uncaught-eoverflow-in-printf-core.patch | 390 +
 .../patches/048-math-fix-pow-signed-shift-ub.patch |  38 ++
 .../049-fix-clock_nanosleep-error-case.patch   |  30 ++
 .../musl/patches/050-add-pthread_setname_np.patch  |  58 +++
 ...at-formatting-of-some-exact-halfway-cases.patch |  30 ++
 ...pt_long_only-misinterpreting-as-an-option.patch |  24 ++
 ...gratuitous-undefined-behavior-in-strptime.patch |  33 ++
 ...-strtof-rounding-with-many-trailing-zeros.patch |  36 ++
 ...optimization-in-non-nearest-rounding-mode.patch |  38 ++
 ...teger-overflow-of-tm_year-in-__secs_to_tm.patch |  39 +++
 ...-internal-buffer-state-and-error-handling.patch |  36 ++
 ...gression-on-archs-with-variable-page-size.patch |  32 ++
 26 files changed, 1513 insertions(+)
 create mode 100644 
toolchain/musl/patches/005-fix-asctime-day-month-names-not-to-vary-by-locale.patch
 create mode 100644 
toolchain/musl/patches/015-fix-pread-pwrite-syscall-calling-convention-on-sh.patch
 create mode 100644 
toolchain/musl/patches/020-verify-that-ttyname-refers-to-the-same-file-as-the-fd.patch
 create mode 100644 
toolchain/musl/patches/025-fix-ffsync-by-changing-it-to-osync.patch
 create mode 100644 
toolchain/musl/patches/028-fix-printf-regression-with-alt-form-octal-zero-flag-and-field-width.patch
 create mode 100644 
toolchain/musl/patches/029-fix-ifru_data-and-ifcu_buf-types-in-net-if.h.patch
 create mode 100644 
toolchain/musl/patches/030-fix-if_indextoname-error-case.patch
 create mode 100644 
toolchain/musl/patches/031-add-missing-unlocked-and-wcsftime_l-prototypes-to-wchar-header.patch
 create mode 100644 
toolchain/musl/patches/033-fix-undefined-behavior-in-sched.h-cpu_set_t-usage.patch
 create mode 100644 
toolchain/musl/patches/035-fix-getservby_r-result-pointer-value-on-error.patch
 create mode 100644 
toolchain/musl/patches/036-fix-strftime-y-for-negative-tm_year.patch
 create mode 100644 
toolchain/musl/patches/037-fix-missing-integer-overflow-checks-in-regexec-buffer-size-computations.patch
 create mode 100644 
toolchain/musl/patches/038-fix-regexec-with-haystack-strings-longer-than-int_max.patch
 create mode 100644 
toolchain/musl/patches/039-fix-integer-overflow-in-float-printf-needed-precision-computation.patch
 create mode 100644 
toolchain/musl/patches/040-fix-integer-overflows-and-uncaught-eoverflow-in-printf-core.patch
 create mode 100644 
toolchain/musl/patches/048-math-fix-pow-signed-shift-ub.patch
 create mode 100644 
toolchain/musl/patches/049-fix-clock_nanosleep-error-case.patch
 create mode 100644 toolchain/musl/patches/050-add-pthread_setname_np.patch
 create mode 100644 
toolchain/musl/patches/051-fix-float-formatting-of-some-exact-halfway-cases.patch
 create mode 100644 
toolchain/musl/patches/052-fix-getopt_long_only-misinterpreting-as-an-option.patch
 create mode 100644 
toolchain/musl/patches/053-fix-gratuitous-undefined-behavior-in-strptime.patch
 create mode 100644 
toolchain/musl/patches/054-fix-strtod-and-strtof-rounding-with-many-trailing-zeros.patch
 create mode 100644 
toolchain/musl/patches/055-fix-strtod-int-optimization-in-non-nearest-rounding-mode.patch
 create mode 100644 
toolchain/musl/patches/065-fix-integer-overflow-of-tm_year-in-__secs_to_tm.patch
 create mode 100644 
toolchain/musl/patches/066-fix-swprintf-internal-buffer-state-and-error-handling.patch
 create mode 100644 
toolchain/musl/patches/071-fix-build-regression-on-archs-with-variable-page-size.patch

diff --git 
a/toolchain/musl/patches/005-fix-asctime-day-month-names-not-to-vary-by-locale.patch
 
b/toolchain/musl/patches/005-fix-asctime-day-month-names-not-to-vary-by-locale.patch
new file mode 100644
index 000..c0e0238
--- /dev/null
+++ 
b/toolchain/musl/patches/005-fix-asctime-day-month-names-not-to-vary-by-locale.patch
@@ -0,0 +1,41 @@
+From 6399fa9d29ea83de4735680b77d457bd59606532 Mon Sep 17 00:00:00 2001
+From: Rich Felker 

[LEDE-DEV] [PATCH v2 1/3] musl: rename a custom backport patch

[Koen Vandeputte]

Ensure there is room in the numbering for next patches

Signed-off-by: Koen Vandeputte 
---
 ...t-attribute-to-some-function-declarations.patch | 197 -
 ...t-attribute-to-some-function-declarations.patch | 197 +
 2 files changed, 197 insertions(+), 197 deletions(-)
 delete mode 100644 
toolchain/musl/patches/040-Add-format-attribute-to-some-function-declarations.patch
 create mode 100644 
toolchain/musl/patches/099-Add-format-attribute-to-some-function-declarations.patch

diff --git 
a/toolchain/musl/patches/040-Add-format-attribute-to-some-function-declarations.patch
 
b/toolchain/musl/patches/040-Add-format-attribute-to-some-function-declarations.patch
deleted file mode 100644
index c495d67..000
--- 
a/toolchain/musl/patches/040-Add-format-attribute-to-some-function-declarations.patch
+++ /dev/null
@@ -1,197 +0,0 @@
-From e6683d001a95d7c3d4d992496f00f77e01fcd268 Mon Sep 17 00:00:00 2001
-From: Hauke Mehrtens 
-Date: Sun, 22 Nov 2015 15:04:23 +0100
-Subject: [PATCH v2] Add format attribute to some function declarations
-
-GCC and Clang are able to check the format arguments given to a
-function and warn the user if there is a error in the format arguments
-or if there is a potential uncontrolled format string security problem
-in the code. GCC does this automatically for some functions like
-printf(), but it is also possible to annotate other functions in a way
-that it will check them too. This feature is used by glibc for many
-functions. This patch adds the attribute to the some functions of musl
-expect for these functions where gcc automatically adds it.
-
-GCC automatically adds checks for these functions: printf, fprintf,
-sprintf, scanf, fscanf, sscanf, strftime, vprintf, vfprintf and
-vsprintf.
-
-The documentation from gcc is here:
-https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
-
-The documentation from Clang is here:
-http://clang.llvm.org/docs/AttributeReference.html#format-gnu-format
-
-Signed-off-by: Hauke Mehrtens 

- include/err.h  | 26 +-
- include/monetary.h | 12 ++--
- include/stdio.h| 29 -
- include/syslog.h   | 12 ++--
- 4 files changed, 57 insertions(+), 22 deletions(-)
-
 a/include/err.h
-+++ b/include/err.h
-@@ -8,15 +8,23 @@
- extern "C" {
- #endif
- 
--void warn(const char *, ...);
--void vwarn(const char *, va_list);
--void warnx(const char *, ...);
--void vwarnx(const char *, va_list);
-+#if __GNUC__ >= 3
-+#define __fp(x, y) __attribute__ ((__format__ (__printf__, x, y)))
-+#else
-+#define __fp(x, y)
-+#endif
- 
--_Noreturn void err(int, const char *, ...);
--_Noreturn void verr(int, const char *, va_list);
--_Noreturn void errx(int, const char *, ...);
--_Noreturn void verrx(int, const char *, va_list);
-+void warn(const char *, ...) __fp(1, 2);
-+void vwarn(const char *, va_list) __fp(1, 0);
-+void warnx(const char *, ...) __fp(1, 2);
-+void vwarnx(const char *, va_list) __fp(1, 0);
-+
-+_Noreturn void err(int, const char *, ...) __fp(2, 3);
-+_Noreturn void verr(int, const char *, va_list) __fp(2, 0);
-+_Noreturn void errx(int, const char *, ...) __fp(2, 3);
-+_Noreturn void verrx(int, const char *, va_list) __fp(2, 0);
-+
-+#undef __fp
- 
- #ifdef __cplusplus
- }
 a/include/monetary.h
-+++ b/include/monetary.h
-@@ -13,8 +13,16 @@ extern "C" {
- 
- #include 
- 
--ssize_t strfmon(char *__restrict, size_t, const char *__restrict, ...);
--ssize_t strfmon_l(char *__restrict, size_t, locale_t, const char *__restrict, 
...);
-+#if __GNUC__ >= 3
-+#define __fsfm(x, y) __attribute__ ((__format__ (__strfmon__, x, y)))
-+#else
-+#define __fsfm(x, y)
-+#endif
-+
-+ssize_t strfmon(char *__restrict, size_t, const char *__restrict, ...) 
__fsfm(3, 4);
-+ssize_t strfmon_l(char *__restrict, size_t, locale_t, const char *__restrict, 
...) __fsfm(4, 5);
-+
-+#undef __fsfm
- 
- #ifdef __cplusplus
- }
 a/include/stdio.h
-+++ b/include/stdio.h
-@@ -21,6 +21,14 @@ extern "C" {
- 
- #include 
- 
-+#if __GNUC__ >= 3
-+#define __fp(x, y) __attribute__ ((__format__ (__printf__, x, y)))
-+#define __fs(x, y) __attribute__ ((__format__ (__scanf__, x, y)))
-+#else
-+#define __fp(x, y)
-+#define __fs(x, y)
-+#endif
-+
- #ifdef __cplusplus
- #define NULL 0L
- #else
-@@ -102,19 +110,19 @@ int puts(const char *);
- int printf(const char *__restrict, ...);
- int fprintf(FILE *__restrict, const char *__restrict, ...);
- int sprintf(char *__restrict, const char *__restrict, ...);
--int snprintf(char *__restrict, size_t, const char *__restrict, ...);
-+int snprintf(char *__restrict, size_t, const char *__restrict, ...) __fp(3, 
4);
- 
- int vprintf(const char *__restrict, __isoc_va_list);
- int vfprintf(FILE *__restrict, const char *__restrict, __isoc_va_list);
- int vsprintf(char *__restrict, const char *__restrict, __isoc_va_list);
--int vsnprintf(char *__restrict, size_t, const char 

Re: [LEDE-DEV] [OpenWrt-Users] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[Karl O. Pinc]

On Thu, 22 Dec 2016 00:58:22 -0800 (PST)
David Lang  wrote:

> On Thu, 22 Dec 2016, John Crispin wrote:

> > claiming that there is only one option and no alternatives is just
> > not constructive and wont lead to a broad discussion during which
> > we can find a consensus.  
> 
> sorry, I did not mean to imply there is only one option.

IMHO if you want to add "freshness" and still leverage the
old brand you do something like, e.g., Pepsi Zero.  You do
"The OpenWRT LEDE Edition!".

Just a thought.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

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

Re: [LEDE-DEV] [PATCH] musl: backport various post-1.1.15 fixes

[Dave Taht]

I am curious as to why musl's release rate has slowed down so much.
1.15 was back in june.

"musl generally follows a time-based release cycle, with versions
spaced roughly one to three months apart."

The commit history since then is quite small. Is it because it's
"done"? If so, it seems sane to try and ship the latest.

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

Re: [LEDE-DEV] [PATCH] musl: backport various post-1.1.15 fixes

[Koen Vandeputte]

On 2016-12-22 16:27, Felix Fietkau wrote:

I think we should probably just update musl to current git instead, and
avoid carrying so many patches.

- Felix




Hi Felix,

This patch was born out of the discussion below:

Besides the method being used (patches vs HEAD bump),
what is your opinion on adding these fixes close to branch-day?



On 22/12/2016 13:19, Koen Vandeputte wrote:


On 2016-12-21 20:13, Jo-Philipp Wich wrote:

- Are there any outstanding changes?

Is there important changes we should wait for before branching the
release? Is there pending stuff in the staging trees which should
absolutely go into the first release?


Bump musl to a newer head? (or better to backport some fixes?)


i thinkt hat bumping the libc shortly before the release is a really bad
idea. it might fix some problems but can introduce some regressions


I see a lot of fixes since 1.1.15 on important parts which could
influence stability as a lot of packages depend on musl:


backporting would be an option. could you provide a patch adding these
fixes ?

John



--
Koen Vandeputte - Software Developer
koen.vandepu...@ncentric.com | +32499736158


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

Re: [LEDE-DEV] [PATCH] musl: backport various post-1.1.15 fixes

[Felix Fietkau]

On 2016-12-22 16:27, Felix Fietkau wrote:
> On 2016-12-22 16:18, John Crispin wrote:
>> please split this into 2 patches.
>> 
>> * add new ones
>> * refresh the rest.
>> 
>> right now its impossible to review this as the 2 kinds of changes are
>> intermingled
> I think we should probably just update musl to current git instead, and
> avoid carrying so many patches.
If we go with backport patches instead, it would be a good idea to leave
out any patches that touch architectures that we don't even support
(e.g. sh) to keep things more readable.

- Felix


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

Re: [LEDE-DEV] [PATCH] musl: backport various post-1.1.15 fixes

[Felix Fietkau]

On 2016-12-22 16:18, John Crispin wrote:
> please split this into 2 patches.
> 
> * add new ones
> * refresh the rest.
> 
> right now its impossible to review this as the 2 kinds of changes are
> intermingled
I think we should probably just update musl to current git instead, and
avoid carrying so many patches.

- Felix


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

Re: [LEDE-DEV] [PATCH] musl: backport various post-1.1.15 fixes

[John Crispin]

please split this into 2 patches.

* add new ones
* refresh the rest.

right now its impossible to review this as the 2 kinds of changes are
intermingled

John


On 22/12/2016 16:11, Koen Vandeputte wrote:
> Backport most important fixes up to latest HEAD
> 
> - Refreshed patches
> - Taken post-commit reverts/fixes into account
> 
> Compile tested
> Run-tested on cns3xxx & imx6 targets
> 
> Signed-off-by: Koen Vandeputte 
> ---
>  ...ime-day-month-names-not-to-vary-by-locale.patch |  41 +++
>  ...d-pwrite-syscall-calling-convention-on-sh.patch |  71 
>  ...ttyname-refers-to-the-same-file-as-the-fd.patch |  49 +++
>  .../025-fix-ffsync-by-changing-it-to-osync.patch   |  25 ++
>  ...-alt-form-octal-zero-flag-and-field-width.patch |  31 ++
>  ...-ifru_data-and-ifcu_buf-types-in-net-if.h.patch |  35 ++
>  .../030-fix-if_indextoname-error-case.patch|  36 ++
>  ...and-wcsftime_l-prototypes-to-wchar-header.patch |  38 ++
>  ...fined-behavior-in-sched.h-cpu_set_t-usage.patch |  43 +++
>  ...getservby_r-result-pointer-value-on-error.patch |  41 +++
>  .../036-fix-strftime-y-for-negative-tm_year.patch  |  23 ++
>  ...hecks-in-regexec-buffer-size-computations.patch |  72 
>  ...with-haystack-strings-longer-than-int_max.patch | 189 ++
>  ...float-printf-needed-precision-computation.patch |  35 ++
>  ...t-attribute-to-some-function-declarations.patch | 197 ---
>  ...ows-and-uncaught-eoverflow-in-printf-core.patch | 390 
> +
>  .../patches/048-math-fix-pow-signed-shift-ub.patch |  38 ++
>  .../049-fix-clock_nanosleep-error-case.patch   |  30 ++
>  .../musl/patches/050-add-pthread_setname_np.patch  |  58 +++
>  ...at-formatting-of-some-exact-halfway-cases.patch |  30 ++
>  ...pt_long_only-misinterpreting-as-an-option.patch |  24 ++
>  ...gratuitous-undefined-behavior-in-strptime.patch |  33 ++
>  ...-strtof-rounding-with-many-trailing-zeros.patch |  36 ++
>  ...optimization-in-non-nearest-rounding-mode.patch |  38 ++
>  ...teger-overflow-of-tm_year-in-__secs_to_tm.patch |  39 +++
>  ...-internal-buffer-state-and-error-handling.patch |  36 ++
>  ...gression-on-archs-with-variable-page-size.patch |  32 ++
>  ...t-attribute-to-some-function-declarations.patch | 197 +++
>  toolchain/musl/patches/300-relative.patch  |   2 +-
>  29 files changed, 1711 insertions(+), 198 deletions(-)
>  create mode 100644 
> toolchain/musl/patches/005-fix-asctime-day-month-names-not-to-vary-by-locale.patch
>  create mode 100644 
> toolchain/musl/patches/015-fix-pread-pwrite-syscall-calling-convention-on-sh.patch
>  create mode 100644 
> toolchain/musl/patches/020-verify-that-ttyname-refers-to-the-same-file-as-the-fd.patch
>  create mode 100644 
> toolchain/musl/patches/025-fix-ffsync-by-changing-it-to-osync.patch
>  create mode 100644 
> toolchain/musl/patches/028-fix-printf-regression-with-alt-form-octal-zero-flag-and-field-width.patch
>  create mode 100644 
> toolchain/musl/patches/029-fix-ifru_data-and-ifcu_buf-types-in-net-if.h.patch
>  create mode 100644 
> toolchain/musl/patches/030-fix-if_indextoname-error-case.patch
>  create mode 100644 
> toolchain/musl/patches/031-add-missing-unlocked-and-wcsftime_l-prototypes-to-wchar-header.patch
>  create mode 100644 
> toolchain/musl/patches/033-fix-undefined-behavior-in-sched.h-cpu_set_t-usage.patch
>  create mode 100644 
> toolchain/musl/patches/035-fix-getservby_r-result-pointer-value-on-error.patch
>  create mode 100644 
> toolchain/musl/patches/036-fix-strftime-y-for-negative-tm_year.patch
>  create mode 100644 
> toolchain/musl/patches/037-fix-missing-integer-overflow-checks-in-regexec-buffer-size-computations.patch
>  create mode 100644 
> toolchain/musl/patches/038-fix-regexec-with-haystack-strings-longer-than-int_max.patch
>  create mode 100644 
> toolchain/musl/patches/039-fix-integer-overflow-in-float-printf-needed-precision-computation.patch
>  delete mode 100644 
> toolchain/musl/patches/040-Add-format-attribute-to-some-function-declarations.patch
>  create mode 100644 
> toolchain/musl/patches/040-fix-integer-overflows-and-uncaught-eoverflow-in-printf-core.patch
>  create mode 100644 
> toolchain/musl/patches/048-math-fix-pow-signed-shift-ub.patch
>  create mode 100644 
> toolchain/musl/patches/049-fix-clock_nanosleep-error-case.patch
>  create mode 100644 toolchain/musl/patches/050-add-pthread_setname_np.patch
>  create mode 100644 
> toolchain/musl/patches/051-fix-float-formatting-of-some-exact-halfway-cases.patch
>  create mode 100644 
> toolchain/musl/patches/052-fix-getopt_long_only-misinterpreting-as-an-option.patch
>  create mode 100644 
> toolchain/musl/patches/053-fix-gratuitous-undefined-behavior-in-strptime.patch
>  create mode 100644 
> toolchain/musl/patches/054-fix-strtod-and-strtof-rounding-with-many-trailing-zeros.patch
>  create mode 100644 
> toolchain/musl/patches/055-fix-strtod-int-optimization-in-non-nearest-rounding-mode.patch
>  create mode 100644 
> 

[LEDE-DEV] [PATCH] musl: backport various post-1.1.15 fixes

[Koen Vandeputte]

Backport most important fixes up to latest HEAD

- Refreshed patches
- Taken post-commit reverts/fixes into account

Compile tested
Run-tested on cns3xxx & imx6 targets

Signed-off-by: Koen Vandeputte 
---
 ...ime-day-month-names-not-to-vary-by-locale.patch |  41 +++
 ...d-pwrite-syscall-calling-convention-on-sh.patch |  71 
 ...ttyname-refers-to-the-same-file-as-the-fd.patch |  49 +++
 .../025-fix-ffsync-by-changing-it-to-osync.patch   |  25 ++
 ...-alt-form-octal-zero-flag-and-field-width.patch |  31 ++
 ...-ifru_data-and-ifcu_buf-types-in-net-if.h.patch |  35 ++
 .../030-fix-if_indextoname-error-case.patch|  36 ++
 ...and-wcsftime_l-prototypes-to-wchar-header.patch |  38 ++
 ...fined-behavior-in-sched.h-cpu_set_t-usage.patch |  43 +++
 ...getservby_r-result-pointer-value-on-error.patch |  41 +++
 .../036-fix-strftime-y-for-negative-tm_year.patch  |  23 ++
 ...hecks-in-regexec-buffer-size-computations.patch |  72 
 ...with-haystack-strings-longer-than-int_max.patch | 189 ++
 ...float-printf-needed-precision-computation.patch |  35 ++
 ...t-attribute-to-some-function-declarations.patch | 197 ---
 ...ows-and-uncaught-eoverflow-in-printf-core.patch | 390 +
 .../patches/048-math-fix-pow-signed-shift-ub.patch |  38 ++
 .../049-fix-clock_nanosleep-error-case.patch   |  30 ++
 .../musl/patches/050-add-pthread_setname_np.patch  |  58 +++
 ...at-formatting-of-some-exact-halfway-cases.patch |  30 ++
 ...pt_long_only-misinterpreting-as-an-option.patch |  24 ++
 ...gratuitous-undefined-behavior-in-strptime.patch |  33 ++
 ...-strtof-rounding-with-many-trailing-zeros.patch |  36 ++
 ...optimization-in-non-nearest-rounding-mode.patch |  38 ++
 ...teger-overflow-of-tm_year-in-__secs_to_tm.patch |  39 +++
 ...-internal-buffer-state-and-error-handling.patch |  36 ++
 ...gression-on-archs-with-variable-page-size.patch |  32 ++
 ...t-attribute-to-some-function-declarations.patch | 197 +++
 toolchain/musl/patches/300-relative.patch  |   2 +-
 29 files changed, 1711 insertions(+), 198 deletions(-)
 create mode 100644 
toolchain/musl/patches/005-fix-asctime-day-month-names-not-to-vary-by-locale.patch
 create mode 100644 
toolchain/musl/patches/015-fix-pread-pwrite-syscall-calling-convention-on-sh.patch
 create mode 100644 
toolchain/musl/patches/020-verify-that-ttyname-refers-to-the-same-file-as-the-fd.patch
 create mode 100644 
toolchain/musl/patches/025-fix-ffsync-by-changing-it-to-osync.patch
 create mode 100644 
toolchain/musl/patches/028-fix-printf-regression-with-alt-form-octal-zero-flag-and-field-width.patch
 create mode 100644 
toolchain/musl/patches/029-fix-ifru_data-and-ifcu_buf-types-in-net-if.h.patch
 create mode 100644 
toolchain/musl/patches/030-fix-if_indextoname-error-case.patch
 create mode 100644 
toolchain/musl/patches/031-add-missing-unlocked-and-wcsftime_l-prototypes-to-wchar-header.patch
 create mode 100644 
toolchain/musl/patches/033-fix-undefined-behavior-in-sched.h-cpu_set_t-usage.patch
 create mode 100644 
toolchain/musl/patches/035-fix-getservby_r-result-pointer-value-on-error.patch
 create mode 100644 
toolchain/musl/patches/036-fix-strftime-y-for-negative-tm_year.patch
 create mode 100644 
toolchain/musl/patches/037-fix-missing-integer-overflow-checks-in-regexec-buffer-size-computations.patch
 create mode 100644 
toolchain/musl/patches/038-fix-regexec-with-haystack-strings-longer-than-int_max.patch
 create mode 100644 
toolchain/musl/patches/039-fix-integer-overflow-in-float-printf-needed-precision-computation.patch
 delete mode 100644 
toolchain/musl/patches/040-Add-format-attribute-to-some-function-declarations.patch
 create mode 100644 
toolchain/musl/patches/040-fix-integer-overflows-and-uncaught-eoverflow-in-printf-core.patch
 create mode 100644 
toolchain/musl/patches/048-math-fix-pow-signed-shift-ub.patch
 create mode 100644 
toolchain/musl/patches/049-fix-clock_nanosleep-error-case.patch
 create mode 100644 toolchain/musl/patches/050-add-pthread_setname_np.patch
 create mode 100644 
toolchain/musl/patches/051-fix-float-formatting-of-some-exact-halfway-cases.patch
 create mode 100644 
toolchain/musl/patches/052-fix-getopt_long_only-misinterpreting-as-an-option.patch
 create mode 100644 
toolchain/musl/patches/053-fix-gratuitous-undefined-behavior-in-strptime.patch
 create mode 100644 
toolchain/musl/patches/054-fix-strtod-and-strtof-rounding-with-many-trailing-zeros.patch
 create mode 100644 
toolchain/musl/patches/055-fix-strtod-int-optimization-in-non-nearest-rounding-mode.patch
 create mode 100644 
toolchain/musl/patches/065-fix-integer-overflow-of-tm_year-in-__secs_to_tm.patch
 create mode 100644 
toolchain/musl/patches/066-fix-swprintf-internal-buffer-state-and-error-handling.patch
 create mode 100644 
toolchain/musl/patches/071-fix-build-regression-on-archs-with-variable-page-size.patch
 create mode 100644 

Re: [LEDE-DEV] Release planning

[Christian Lamparter 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 ---
On Thursday, December 22, 2016 1:19:46 PM CET Koen Vandeputte wrote:
> 
> On 2016-12-21 20:13, Jo-Philipp Wich wrote:
> > - Are there any outstanding changes?
> >
> >Is there important changes we should wait for before branching the
> >release? Is there pending stuff in the staging trees which should
> >absolutely go into the first release?
> >
> Bump musl to a newer head? (or better to backport some fixes?)
> 
> I see a lot of fixes since 1.1.15 on important parts which could 
> influence stability as a lot of packages depend on musl:
> 
> http://git.musl-libc.org/cgit/musl/log/
> 
> Some examples:
>  fix build regression on archs with variable page size
>  fix swprintf internal buffer state and error handling
[...]

Well, if anyone is interested, here's a stand-alone patch for building
musl from git [0]. There's a small problem though with using GIT and
not point releases. It's because the musl version is used in the target and
toolchain triplet so unless you want ridiculously long names like
target-arm_cortex-a7+neon-vfpv4_musl-4c487165ff074e2f3fe7116140d1d9cded95b018_eabi

so I opt to just use 1.1.16 which unfortunately has the downside that
it's not getting updated automatically.

[0] 


Regards,
Christian

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

Re: [LEDE-DEV] Release planning

[John Crispin]

On 22/12/2016 13:42, Rafał Miłecki wrote:
> On 21 December 2016 at 20:13, Jo-Philipp Wich  wrote:
>> - Are there any outstanding changes?
>>
>>   Is there important changes we should wait for before branching the
>>   release? Is there pending stuff in the staging trees which should
>>   absolutely go into the first release?
> 
> 1) Possible brcmfmac fix
> I'm working on this for last few days, if that happens to work, it may
> improve brcmfmac stability.
> 
> 2) Better support for tri-band devices in brcmfmac
> I didn't start working on this yet, but it should be easy and many
> people were complaining on this issue.
> 
> 3) Per device rootfs for brcm47xx
> Everything is prepared, I just need to make sure rootfs don't get
> bigger and then I need to specify packages.
> 
> 
>> - When do we want to branch?
>>
>>   Personally I'd like to branch before Christmas so that we can use the
>>   free time for building images (it takes about 8 days and ~2TB of space
>>   to build all targets and all packages).
> 
> This gives us a very short period for working on extra features, I'd
> appreciate something like 2 weeks at least.
> 

would starting the builders on the monday 9th of january work ? that
would give is a 17.01 release

John

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

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

Re: [LEDE-DEV] Release planning

[Jo-Philipp Wich]

Hi Rafał,

> 1) Possible brcmfmac fix
> I'm working on this for last few days, if that happens to work, it may
> improve brcmfmac stability.

Noted.

> 2) Better support for tri-band devices in brcmfmac
> I didn't start working on this yet, but it should be easy and many
> people were complaining on this issue.

Noted.

> 3) Per device rootfs for brcm47xx
> Everything is prepared, I just need to make sure rootfs don't get
> bigger and then I need to specify packages.

Noted.

> This gives us a very short period for working on extra features, I'd
> appreciate something like 2 weeks at least.

Sure thing, realistically I think the branching will happen early
sometime in January.


~ Jo



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

Re: [LEDE-DEV] Release planning

[Rafał Miłecki]

On 21 December 2016 at 20:13, Jo-Philipp Wich  wrote:
> - Are there any outstanding changes?
>
>   Is there important changes we should wait for before branching the
>   release? Is there pending stuff in the staging trees which should
>   absolutely go into the first release?

1) Possible brcmfmac fix
I'm working on this for last few days, if that happens to work, it may
improve brcmfmac stability.

2) Better support for tri-band devices in brcmfmac
I didn't start working on this yet, but it should be easy and many
people were complaining on this issue.

3) Per device rootfs for brcm47xx
Everything is prepared, I just need to make sure rootfs don't get
bigger and then I need to specify packages.


> - When do we want to branch?
>
>   Personally I'd like to branch before Christmas so that we can use the
>   free time for building images (it takes about 8 days and ~2TB of space
>   to build all targets and all packages).

This gives us a very short period for working on extra features, I'd
appreciate something like 2 weeks at least.

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

Re: [LEDE-DEV] Release planning

[John Crispin]

On 22/12/2016 13:19, Koen Vandeputte wrote:
> 
> On 2016-12-21 20:13, Jo-Philipp Wich wrote:
>> - Are there any outstanding changes?
>>
>>Is there important changes we should wait for before branching the
>>release? Is there pending stuff in the staging trees which should
>>absolutely go into the first release?
>>
> Bump musl to a newer head? (or better to backport some fixes?)
> 

i thinkt hat bumping the libc shortly before the release is a really bad
idea. it might fix some problems but can introduce some regressions

> I see a lot of fixes since 1.1.15 on important parts which could
> influence stability as a lot of packages depend on musl:
> 

backporting would be an option. could you provide a patch adding these
fixes ?

John

> http://git.musl-libc.org/cgit/musl/log/
> 
> Some examples:
> fix build regression on archs with variable page size
> fix swprintf internal buffer state and error handling
> fix integer overflow of tm_year in __secs_to_tm
> fix minor problem in previous strtod non-nearest rounding bug fix
> fix strtod int optimization in non-nearest rounding mode
> fix strtod and strtof rounding with many trailing zeros
> fix gratuitous undefined behavior in strptime
> fix float formatting of some exact halfway cases
> add pthread_setname_np (useful for debugging)
> fix clock_nanosleep error case
> math: fix pow signed shift ub
> fix integer overflows and uncaught EOVERFLOW in printf core
> fix integer overflow in float printf needed-precision computation
> fix regexec with haystack strings longer than INT_MAX
> fix missing integer overflow checks in regexec buffer size computations
> fix strftime %y for negative tm_year
> fix getservby*_r result pointer value on error
> fix undefined behavior in sched.h cpu_set_t usage
> add missing *_unlocked and wcsftime_l prototypes to wchar.h
> fix if_indextoname error case
> fix ifru_data and ifcu_buf types in net/if.h
> fix printf regression with alt-form octal, zero flag, and field width
> fix FFSYNC by changing it to O_SYNC
> verify that ttyname refers to the same file as the fd
> fix pread/pwrite syscall calling convention on sh
> fix regression in tcsetattr on all mips archs
> fix asctime day/month names not to vary by locale
> 
> 
> Please share your view on this one :-)
> 
> Thanks
> 

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

Re: [LEDE-DEV] Release planning

[Koen Vandeputte]

On 2016-12-21 20:13, Jo-Philipp Wich wrote:

- Are there any outstanding changes?

   Is there important changes we should wait for before branching the
   release? Is there pending stuff in the staging trees which should
   absolutely go into the first release?


Bump musl to a newer head? (or better to backport some fixes?)

I see a lot of fixes since 1.1.15 on important parts which could 
influence stability as a lot of packages depend on musl:


http://git.musl-libc.org/cgit/musl/log/

Some examples:
fix build regression on archs with variable page size
fix swprintf internal buffer state and error handling
fix integer overflow of tm_year in __secs_to_tm
fix minor problem in previous strtod non-nearest rounding bug fix
fix strtod int optimization in non-nearest rounding mode
fix strtod and strtof rounding with many trailing zeros
fix gratuitous undefined behavior in strptime
fix float formatting of some exact halfway cases
add pthread_setname_np (useful for debugging)
fix clock_nanosleep error case
math: fix pow signed shift ub
fix integer overflows and uncaught EOVERFLOW in printf core
fix integer overflow in float printf needed-precision computation
fix regexec with haystack strings longer than INT_MAX
fix missing integer overflow checks in regexec buffer size computations
fix strftime %y for negative tm_year
fix getservby*_r result pointer value on error
fix undefined behavior in sched.h cpu_set_t usage
add missing *_unlocked and wcsftime_l prototypes to wchar.h
fix if_indextoname error case
fix ifru_data and ifcu_buf types in net/if.h
fix printf regression with alt-form octal, zero flag, and field width
fix FFSYNC by changing it to O_SYNC
verify that ttyname refers to the same file as the fd
fix pread/pwrite syscall calling convention on sh
fix regression in tcsetattr on all mips archs
fix asctime day/month names not to vary by locale


Please share your view on this one :-)

Thanks

--
Koen Vandeputte - Software Developer
koen.vandepu...@ncentric.com | +32499736158


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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[Paul Oranje]

Nevertheless, wouldn’t it be wise to ask SPI to also handle trademark issues 
around the name lede(-project) ?

Irrespective of the outcome of this discussion about which name to use when the 
projects would be merged, having some protection around the name seems wise and 
SPI exists for that very reason 
(https://en.wikipedia.org/wiki/Software_in_the_Public_Interest). BTW, the TM 
record for LEDE mentioned by Dave has USPTO serial number 86650406.

And about what name to choose, the banner (shell) for LEDE looks much, much, 
nicer than that of OpenWRT.
To leverage the general fame of OpenWRT, as already suggested by John, 
redirects and keeping archives of (outdated) documentation would probably 
suffice.

— 
Paul Oranje


> Op 22 dec. 2016, om 08:17 heeft John Crispin  het volgende 
> geschreven:
> 
> 
> 
> On 22/12/2016 04:45, Dave Taht wrote:
>> Lede trademark...
>> 
>> Published for Opposition:December 20, 2016
>> 
>> sigh.
>> 
> 
> *slap on the wrist or top posting*
> 
> the project is called lede-project and not lede for a reason ;)
> 
>   John
> 





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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[John Crispin]

On 22/12/2016 09:58, David Lang wrote:
> On Thu, 22 Dec 2016, John Crispin wrote:
> 
>> On 22/12/2016 09:42, David Lang wrote:
>>> On Thu, 22 Dec 2016, John Crispin wrote:
>>>
> Yes, the name is pointing at a product that doesn't exist any longer,
> but Deb and Ian aren't involved with Debian any longer either. At some
> point the fact that a name is known matters far more than the
> historical
> reasons for the name.

 a problem that can be solved by a http redirect ...
>>>
>>> Is that going to break all links in discussions that point at OpenWRT
>>> docs and/or forum threads?
>>>
>>> That's a high cost.
>>>
>>> David Lang
>>
>> it is something worth considering if the alternative content is
>> available and easy to look up and if we keep archives in ro mode of
>> existing content.
>>
>> claiming that there is only one option and no alternatives is just not
>> constructive and wont lead to a broad discussion during which we can
>> find a consensus.
> 
> sorry, I did not mean to imply there is only one option.
> 
> I think there is a lot of value in the OpenWRT name and all the links
> around the web that refer to it. So there is a huge cost to going with a
> different name.
> 
> IMHO, this makes it an easy decision to make, but not the only one
> possible.

well i think you are just not considering options properly but simply
claiming that this is the easy road to take so lets take it. i find your
mail to be the contrary of something that can be used to start a broad
discussion which will hopefully lead to a consensus.

John



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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[David Lang]

On Thu, 22 Dec 2016, John Crispin wrote:


On 22/12/2016 09:42, David Lang wrote:

On Thu, 22 Dec 2016, John Crispin wrote:


Yes, the name is pointing at a product that doesn't exist any longer,
but Deb and Ian aren't involved with Debian any longer either. At some
point the fact that a name is known matters far more than the historical
reasons for the name.


a problem that can be solved by a http redirect ...


Is that going to break all links in discussions that point at OpenWRT
docs and/or forum threads?

That's a high cost.

David Lang


it is something worth considering if the alternative content is
available and easy to look up and if we keep archives in ro mode of
existing content.

claiming that there is only one option and no alternatives is just not
constructive and wont lead to a broad discussion during which we can
find a consensus.


sorry, I did not mean to imply there is only one option.

I think there is a lot of value in the OpenWRT name and all the links around the 
web that refer to it. So there is a huge cost to going with a different name.


IMHO, this makes it an easy decision to make, but not the only one possible.

David Lang

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

Re: [LEDE-DEV] Release planning

[David Lang]

On Thu, 22 Dec 2016, James Feeney wrote:


On 12/22/2016 01:33 AM, David Lang wrote:

the reason for this is sort order, if something is sorting versions with an
alpha sort, you want the ~rc to show up as older than the YY.MM release, and you
want that to show up as older than the YY.MM.N releases.


A "cleaner looking" format could be "YY.MM.~m" for the release candidates?


cleaner looking but more confusing. people are used to 'rc' 'beta', etc. .~3 
just doesn't have the human readable factor.


David Lang

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[John Crispin]

On 22/12/2016 09:42, David Lang wrote:
> On Thu, 22 Dec 2016, John Crispin wrote:
> 
>>> Yes, the name is pointing at a product that doesn't exist any longer,
>>> but Deb and Ian aren't involved with Debian any longer either. At some
>>> point the fact that a name is known matters far more than the historical
>>> reasons for the name.
>>
>> a problem that can be solved by a http redirect ...
> 
> Is that going to break all links in discussions that point at OpenWRT
> docs and/or forum threads?
> 
> That's a high cost.
> 
> David Lang

it is something worth considering if the alternative content is
available and easy to look up and if we keep archives in ro mode of
existing content.

claiming that there is only one option and no alternatives is just not
constructive and wont lead to a broad discussion during which we can
find a consensus.

John

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[David Lang]

On Thu, 22 Dec 2016, John Crispin wrote:


Yes, the name is pointing at a product that doesn't exist any longer,
but Deb and Ian aren't involved with Debian any longer either. At some
point the fact that a name is known matters far more than the historical
reasons for the name.


a problem that can be solved by a http redirect ...


Is that going to break all links in discussions that point at OpenWRT docs 
and/or forum threads?


That's a high cost.

David Lang

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[John Crispin]

On 22/12/2016 09:40, David Lang wrote:
> On Wed, 21 Dec 2016, Stefan Monnier wrote:
> 
>> - While brands have value, you can change a name without losing all the
>>  brand recognition.  I'm thinking here of cases like XBMC->Kodi or
>>  OpenOffice->LibreOffice.
> 
> I would point at OpenOffice -> LibreOffice as a failure of name changes.
> 
> David Lang

again, they did not change the name as a team but were split. if we
choose to not use owrt but some different name then a simple http
redirect can help solve the problem.

John

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

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[John Crispin]

On 22/12/2016 09:36, David Lang wrote:
> On Wed, 21 Dec 2016, Dave Taht wrote:
> 
>> On Wed, Dec 21, 2016 at 12:29 PM, David Lang  wrote:
>>> On Wed, 21 Dec 2016, Kathy Giori wrote:
>>>
 From a PR perspective, I strongly suggest keeping the term OpenWrt as
 part of the branding of the project moving forward. It can just be
 cosmetic (web site, etc.) but the name has so much history, and
 positive connotation, that you don't want to lose that brand attached
 to the development moving forward.
>>>
>>>
>>> I agree, I think this is an obvious choice to make. OpenWRT has a lot of
>>> name recognition, it would be foolish to throw that away.
>>
>> Just to take the other side for rhetorical purposes, a purpose of a
>> re-branding exercise is to show a change in the "product" or
>> organisation behind it. OpenWrt is widely known... as a bleeding edge,
>> sometimes unstable, somewhat hard to use 3rd party firmware. DD-Wrt
>> and Tomato get a lot more press for some reason. So do things like
>> Yocto. If lede were to succeed in meeting its other goals, coherently,
>> preserving "lede" and moving forward as a separate project does make
>> sense.
> 
> I'll point out OpenOffice vs LibreOffice and the fact that years after
> development of OO has really stopped, people are still finding it and
> downloading it instead of LO (it's replacement)
> 
> there's a lot of stuff out there pointing at OpenWRT, unless you are
> going to replace all the OpenWRT stuff with pointers to LEDE, you are
> better off taking advantage of the millions of references to OpenWRT.
> 
> David Lang
> 
> Yes, the name is pointing at a product that doesn't exist any longer,
> but Deb and Ian aren't involved with Debian any longer either. At some
> point the fact that a name is known matters far more than the historical
> reasons for the name.

a problem that can be solved by a http redirect ...

John




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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[David Lang]

On Wed, 21 Dec 2016, Dave Taht wrote:


On Wed, Dec 21, 2016 at 12:29 PM, David Lang  wrote:

On Wed, 21 Dec 2016, Kathy Giori wrote:


From a PR perspective, I strongly suggest keeping the term OpenWrt as
part of the branding of the project moving forward. It can just be
cosmetic (web site, etc.) but the name has so much history, and
positive connotation, that you don't want to lose that brand attached
to the development moving forward.



I agree, I think this is an obvious choice to make. OpenWRT has a lot of
name recognition, it would be foolish to throw that away.


Just to take the other side for rhetorical purposes, a purpose of a
re-branding exercise is to show a change in the "product" or
organisation behind it. OpenWrt is widely known... as a bleeding edge,
sometimes unstable, somewhat hard to use 3rd party firmware. DD-Wrt
and Tomato get a lot more press for some reason. So do things like
Yocto. If lede were to succeed in meeting its other goals, coherently,
preserving "lede" and moving forward as a separate project does make
sense.


I'll point out OpenOffice vs LibreOffice and the fact that years after 
development of OO has really stopped, people are still finding it and 
downloading it instead of LO (it's replacement)


there's a lot of stuff out there pointing at OpenWRT, unless you are going to 
replace all the OpenWRT stuff with pointers to LEDE, you are better off taking 
advantage of the millions of references to OpenWRT.


David Lang

Yes, the name is pointing at a product that doesn't exist any longer, but Deb 
and Ian aren't involved with Debian any longer either. At some point the fact 
that a name is known matters far more than the historical reasons for the name.


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

Re: [LEDE-DEV] Release planning

[David Lang]

On Thu, 22 Dec 2016, James Feeney wrote:

On 12/21/2016 12:13 PM, Jo-Philipp Wich wrote:



Tags will follow the format "vYY.MM.N[-RC#]" with YY.MM being the base
release version, N being the number of the minor release and an optional
-RC# designating release candidate numbers.


With respect to the version name, do you really want to use a "dash" instead of
a "period", for the release candidate numbers?  I would think that adding the
character string "RC" already provides enough information to distinguish a
release candidate - where the ".n" suffix would be changed to ".RCm" - and that
changing ".n" to "-RCm" just makes this suffix more difficult to parse.  Would
it not be more practical to consistently use a "period" as the suffix delimiter?


I missed this, you don't want to use a dash or a period, you want to use a tilde 
'~'


the reason for this is sort order, if something is sorting versions with an 
alpha sort, you want the ~rc to show up as older than the YY.MM release, and you 
want that to show up as older than the YY.MM.N releases.


David Lang

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[John Crispin]

On 22/12/2016 09:25, James Feeney wrote:
> 
> On 12/22/2016 12:27 AM, John Crispin wrote:
>> or do we want to build a "one stop shop" for embedded linux
> 
> Yes, we do?

!

[...]

> Consider:
> https://en.wikipedia.org/wiki/Comparison_of_single-board_computers
> 
> Does LEDE have builds for all of these products?

Some but not all *yet*

> 
> 
> I imagine that the stable/bleeding-edge issue might be addressed in the same 
> way
> as other projects which have designated "long term support" versions.
> 
> 
> Just for fun:
> https://en.wiktionary.org/wiki/lede
> 

we passed that link around when we first started to consider names. the
actual choice was based on the print media term "the lede article"

John

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