| Message ID | 20171019214148.14908-1-chunkeey@gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [LEDE-DEV] musl: update to 1.1.17 | expand |
Tested this on mvebu/WRT3200ACM, the same issue as I reported before[1]. hostapd and pppd won't start, kernel boots without problems. I'm sure 39db00afadc9d8d0456c46eab42b8cb8ff9f375c works well. something wrong between 39db00afadc9d8d0456c46eab42b8cb8ff9f375c and c10bc61508dc52b8315084e628f36a6c3c2dabb1(last time I tested this commit, it doesn't work, 1.1.17 neither) [1]: https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09180.html Best Regards, Syrone Wong On Fri, Oct 20, 2017 at 5:41 AM, Christian Lamparter <chunkeey@gmail.com> wrote: > This patch updates musl to the latest 1.1.17 release. > > Rick Felker stated in his release note: " > This release fixes numerous bugs affecting visible behavior and > safety/internal consistency, including a stack-based buffer overflow > in dns parsing and multiple sources of invalid memory accesses that > may lead to crashes. See the release notes in WHATSNEW for details. > > Many new features have also been added, including deferred symbol > binding in the dynamic linker (RTLD_LAZY emulation), an option to > overrid argv[0] when running ldso to execute a program, support for > starting new sessions via posix_spawn (POSIX_SPAWN_SETSID, accepted > for standardization), and ability to query the active thread-local > locale (via _NL_LOCALE_NAME extension). Improvements in compatibility > with applications, build tools, and platforms have also been made. > " <http://www.openwall.com/lists/musl/2017/10/19/1> > > The stack-based buffer overflow in dns parsing can be mitigated by: > "running a caching nameserver on localhost and pointing resolv.conf > to 127.0.0.1." <http://www.openwall.com/lists/musl/2017/10/19/2> > Which is the case on the default LEDE installation (dnsmasq). > > Signed-off-by: Christian Lamparter <chunkeey@gmail.com> > --- > toolchain/musl/common.mk | 6 +++--- > toolchain/musl/patches/900-iconv_size_hack.patch | 4 ++-- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk > index 0a45828f79..4c4e5b47ae 100644 > --- a/toolchain/musl/common.mk > +++ b/toolchain/musl/common.mk > @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk > include $(INCLUDE_DIR)/target.mk > > PKG_NAME:=musl > -PKG_VERSION:=1.1.16 > +PKG_VERSION:=1.1.17 > PKG_RELEASE=1 > > PKG_SOURCE_PROTO:=git > PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) > -PKG_SOURCE_VERSION:=5f7efb87a28a311ad377dd26adf53715dedb096d > -PKG_MIRROR_HASH:=da18ef24f270e5cae6bc4c440479da17bec1949ae5a1bc990352ca04f24c4378 > +PKG_SOURCE_VERSION:=2cd663fb2d576d590a08c1e40386c07b378d5ad6 > +PKG_MIRROR_HASH:=e3140faaa9aff51c4f56f36c15d677265a5bed39aa6d9ab5d252f1c49b7c13ca > PKG_SOURCE_URL:=git://git.musl-libc.org/musl > PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz > > diff --git a/toolchain/musl/patches/900-iconv_size_hack.patch b/toolchain/musl/patches/900-iconv_size_hack.patch > index 343915fb06..cfbb7ee5f7 100644 > --- a/toolchain/musl/patches/900-iconv_size_hack.patch > +++ b/toolchain/musl/patches/900-iconv_size_hack.patch > @@ -32,7 +32,7 @@ > > static int fuzzycmp(const unsigned char *a, const unsigned char *b) > { > -@@ -216,6 +220,7 @@ size_t iconv(iconv_t cd0, char **restric > +@@ -224,6 +228,7 @@ size_t iconv(iconv_t cd0, char **restric > c = ((c-0xd7c0)<<10) + (d-0xdc00); > } > break; > @@ -47,7 +47,7 @@ > +#endif > default: > if (c < 128+type) break; > - c -= 128+type; > + c = legacy_map(map, c); > --- a/src/locale/codepages.h > +++ b/src/locale/codepages.h > @@ -118,6 +118,7 @@ > -- > 2.15.0.rc1 > > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev
Hi,
I tested commits between 39db00afadc9d8d0456c46eab42b8cb8ff9f375c and
c10bc61508dc52b8315084e628f36a6c3c2dabb1.
Finally, I find 8c4be3e is causing the problem. 565dbee is the last one working.
Commands below for every libc ipk.
```
make toolchain/musl/{clean,compile} V=99
make package/toolchain/{clean,compile} V=99
cp libc_*.ipk /tmp
tar zxf libc_*.ipk
tar zxf data.tar.gz
cd lib
mv ld-musl-armhf.so.1 libc.so /lib
reboot
```
Best Regards,
Syrone Wong
On Sat, Oct 21, 2017 at 8:10 AM, Syrone Wong <wong.syrone@gmail.com> wrote:
> Tested this on mvebu/WRT3200ACM, the same issue as I reported before[1].
>
> hostapd and pppd won't start, kernel boots without problems.
>
> I'm sure 39db00afadc9d8d0456c46eab42b8cb8ff9f375c works well.
>
> something wrong between 39db00afadc9d8d0456c46eab42b8cb8ff9f375c and
> c10bc61508dc52b8315084e628f36a6c3c2dabb1(last time I tested this
> commit, it doesn't work, 1.1.17 neither)
>
>
> [1]: https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09180.html
>
>
> Best Regards,
> Syrone Wong
>
>
> On Fri, Oct 20, 2017 at 5:41 AM, Christian Lamparter <chunkeey@gmail.com> wrote:
>> This patch updates musl to the latest 1.1.17 release.
>>
>> Rick Felker stated in his release note: "
>> This release fixes numerous bugs affecting visible behavior and
>> safety/internal consistency, including a stack-based buffer overflow
>> in dns parsing and multiple sources of invalid memory accesses that
>> may lead to crashes. See the release notes in WHATSNEW for details.
>>
>> Many new features have also been added, including deferred symbol
>> binding in the dynamic linker (RTLD_LAZY emulation), an option to
>> overrid argv[0] when running ldso to execute a program, support for
>> starting new sessions via posix_spawn (POSIX_SPAWN_SETSID, accepted
>> for standardization), and ability to query the active thread-local
>> locale (via _NL_LOCALE_NAME extension). Improvements in compatibility
>> with applications, build tools, and platforms have also been made.
>> " <http://www.openwall.com/lists/musl/2017/10/19/1>
>>
>> The stack-based buffer overflow in dns parsing can be mitigated by:
>> "running a caching nameserver on localhost and pointing resolv.conf
>> to 127.0.0.1." <http://www.openwall.com/lists/musl/2017/10/19/2>
>> Which is the case on the default LEDE installation (dnsmasq).
>>
>> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
>> ---
>> toolchain/musl/common.mk | 6 +++---
>> toolchain/musl/patches/900-iconv_size_hack.patch | 4 ++--
>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk
>> index 0a45828f79..4c4e5b47ae 100644
>> --- a/toolchain/musl/common.mk
>> +++ b/toolchain/musl/common.mk
>> @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk
>> include $(INCLUDE_DIR)/target.mk
>>
>> PKG_NAME:=musl
>> -PKG_VERSION:=1.1.16
>> +PKG_VERSION:=1.1.17
>> PKG_RELEASE=1
>>
>> PKG_SOURCE_PROTO:=git
>> PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
>> -PKG_SOURCE_VERSION:=5f7efb87a28a311ad377dd26adf53715dedb096d
>> -PKG_MIRROR_HASH:=da18ef24f270e5cae6bc4c440479da17bec1949ae5a1bc990352ca04f24c4378
>> +PKG_SOURCE_VERSION:=2cd663fb2d576d590a08c1e40386c07b378d5ad6
>> +PKG_MIRROR_HASH:=e3140faaa9aff51c4f56f36c15d677265a5bed39aa6d9ab5d252f1c49b7c13ca
>> PKG_SOURCE_URL:=git://git.musl-libc.org/musl
>> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
>>
>> diff --git a/toolchain/musl/patches/900-iconv_size_hack.patch b/toolchain/musl/patches/900-iconv_size_hack.patch
>> index 343915fb06..cfbb7ee5f7 100644
>> --- a/toolchain/musl/patches/900-iconv_size_hack.patch
>> +++ b/toolchain/musl/patches/900-iconv_size_hack.patch
>> @@ -32,7 +32,7 @@
>>
>> static int fuzzycmp(const unsigned char *a, const unsigned char *b)
>> {
>> -@@ -216,6 +220,7 @@ size_t iconv(iconv_t cd0, char **restric
>> +@@ -224,6 +228,7 @@ size_t iconv(iconv_t cd0, char **restric
>> c = ((c-0xd7c0)<<10) + (d-0xdc00);
>> }
>> break;
>> @@ -47,7 +47,7 @@
>> +#endif
>> default:
>> if (c < 128+type) break;
>> - c -= 128+type;
>> + c = legacy_map(map, c);
>> --- a/src/locale/codepages.h
>> +++ b/src/locale/codepages.h
>> @@ -118,6 +118,7 @@
>> --
>> 2.15.0.rc1
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
On 10/21/2017 07:03 AM, Syrone Wong wrote: > Hi, > > I tested commits between 39db00afadc9d8d0456c46eab42b8cb8ff9f375c and > c10bc61508dc52b8315084e628f36a6c3c2dabb1. > > Finally, I find 8c4be3e is causing the problem. 565dbee is the last one working. > > > Commands below for every libc ipk. > > ``` > make toolchain/musl/{clean,compile} V=99 > make package/toolchain/{clean,compile} V=99 > cp libc_*.ipk /tmp > tar zxf libc_*.ipk > tar zxf data.tar.gz > cd lib > mv ld-musl-armhf.so.1 libc.so /lib > reboot > ``` > > Best Regards, > Syrone Wong Hi Syrone, Could you report this upstream to the musl developers please. Plese also describe in more detail how it is crashing. Hauke
On 10/21/2017 11:58 AM, Hauke Mehrtens wrote: > On 10/21/2017 07:03 AM, Syrone Wong wrote: >> Hi, >> >> I tested commits between 39db00afadc9d8d0456c46eab42b8cb8ff9f375c and >> c10bc61508dc52b8315084e628f36a6c3c2dabb1. >> >> Finally, I find 8c4be3e is causing the problem. 565dbee is the last one working. >> >> >> Commands below for every libc ipk. >> >> ``` >> make toolchain/musl/{clean,compile} V=99 >> make package/toolchain/{clean,compile} V=99 >> cp libc_*.ipk /tmp >> tar zxf libc_*.ipk >> tar zxf data.tar.gz >> cd lib >> mv ld-musl-armhf.so.1 libc.so /lib >> reboot >> ``` >> >> Best Regards, >> Syrone Wong > > Hi Syrone, > > Could you report this upstream to the musl developers please. Plese also > describe in more detail how it is crashing. Hi, I think your problem is fixed in ec04d122f1182aeb91f39b0e80ae40c68e4d9605 fix regression in glob with literal . or .. path component Hauke
Hauke Mehrtens wrote on Sat Oct 21 12:26:04 PDT 2017: > I think your problem is fixed in ec04d122f1182aeb91f39b0e80ae40c68e4d9605 > fix regression in glob with literal . or .. path component Based on musl mailing list, there will likely be a new musl release rather soon: Rich Felker wrote in http://www.openwall.com/lists/musl/2017/10/21/3 > > This was wrong and introduced a regression: literal . and .. in paths passed into glob result in no results. > > ... > > Due to this and a couple small other bugs/regressions, I think it will make sense to make another release right away, to have a solid "works out of the box without patching" one as the latest. Please let me know if you spot other regressions so fixes can be included.
Confirmed fixed via ec04d122f1182aeb91f39b0e80ae40c68e4d9605 Best Regards, Syrone Wong On Sun, Oct 22, 2017 at 3:26 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote: > > > On 10/21/2017 11:58 AM, Hauke Mehrtens wrote: >> On 10/21/2017 07:03 AM, Syrone Wong wrote: >>> Hi, >>> >>> I tested commits between 39db00afadc9d8d0456c46eab42b8cb8ff9f375c and >>> c10bc61508dc52b8315084e628f36a6c3c2dabb1. >>> >>> Finally, I find 8c4be3e is causing the problem. 565dbee is the last one working. >>> >>> >>> Commands below for every libc ipk. >>> >>> ``` >>> make toolchain/musl/{clean,compile} V=99 >>> make package/toolchain/{clean,compile} V=99 >>> cp libc_*.ipk /tmp >>> tar zxf libc_*.ipk >>> tar zxf data.tar.gz >>> cd lib >>> mv ld-musl-armhf.so.1 libc.so /lib >>> reboot >>> ``` >>> >>> Best Regards, >>> Syrone Wong >> >> Hi Syrone, >> >> Could you report this upstream to the musl developers please. Plese also >> describe in more detail how it is crashing. > > Hi, > > I think your problem is fixed in ec04d122f1182aeb91f39b0e80ae40c68e4d9605 > fix regression in glob with literal . or .. path component > > Hauke
On Sunday, October 22, 2017 12:02:07 AM CEST Hannu Nyman wrote: > Hauke Mehrtens wrote on Sat Oct 21 12:26:04 PDT 2017: > > I think your problem is fixed in ec04d122f1182aeb91f39b0e80ae40c68e4d9605 > > fix regression in glob with literal . or .. path component > > Based on musl mailing list, there will likely be a new musl release rather soon: > > Rich Felker wrote in http://www.openwall.com/lists/musl/2017/10/21/3 > > > This was wrong and introduced a regression: literal . and .. in paths > passed into glob result in no results. > > > ... > > > Due to this and a couple small other bugs/regressions, I think it will > make sense to make another release right away, to have a solid "works out of > the box without patching" one as the latest. Please let me know if you spot > other regressions so fixes can be included. Ok, so wait for the next release then, or should I just respin the patch based on the current tree? Regards, Christian
On 29.10.2017 01:08, Christian Lamparter wrote: > On Sunday, October 22, 2017 12:02:07 AM CEST Hannu Nyman wrote: >> Hauke Mehrtens wrote on Sat Oct 21 12:26:04 PDT 2017: >> > I think your problem is fixed in ec04d122f1182aeb91f39b0e80ae40c68e4d9605 >> > fix regression in glob with literal . or .. path component >> >> Based on musl mailing list, there will likely be a new musl release rather soon: >> >> Rich Felker wrote in http://www.openwall.com/lists/musl/2017/10/21/3 >> > > This was wrong and introduced a regression: literal . and .. in paths >> passed into glob result in no results. >> > > ... >> > > Due to this and a couple small other bugs/regressions, I think it will >> make sense to make another release right away, to have a solid "works out of >> the box without patching" one as the latest. Please let me know if you spot >> other regressions so fixes can be included. > Ok, so wait for the next release then, or should I just respin the patch > based on the current tree? > > Regards, > Christian > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev Mainline - 1.1.18 is available Regards
On 01.11.2017 12:08, Lucian Cristian wrote: > On 29.10.2017 01:08, Christian Lamparter wrote: >> On Sunday, October 22, 2017 12:02:07 AM CEST Hannu Nyman wrote: >>> Hauke Mehrtens wrote on Sat Oct 21 12:26:04 PDT 2017: >>> > I think your problem is fixed in >>> ec04d122f1182aeb91f39b0e80ae40c68e4d9605 >>> > fix regression in glob with literal . or .. path component >>> >>> Based on musl mailing list, there will likely be a new musl release >>> rather soon: >>> >>> Rich Felker wrote in http://www.openwall.com/lists/musl/2017/10/21/3 >>> > > This was wrong and introduced a regression: literal . and .. >>> in paths >>> passed into glob result in no results. >>> > > ... >>> > > Due to this and a couple small other bugs/regressions, I think >>> it will >>> make sense to make another release right away, to have a solid >>> "works out of >>> the box without patching" one as the latest. Please let me know if >>> you spot >>> other regressions so fixes can be included. >> Ok, so wait for the next release then, or should I just respin the patch >> based on the current tree? >> >> Regards, >> Christian >> >> _______________________________________________ >> Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev > > Mainline - 1.1.18 is available > > > Regards > > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev on the first try, brief test, for dhcp wan, only issuing manual dhcpc worked, or maybe the tree wasn't clean enough Regards
Lucian Cristian wrote Wed Nov 1 2017 > Mainline - 1.1.18 is available > > on the first try, brief test, for dhcp wan, only issuing manual dhcpc worked, or maybe the tree wasn't clean enough I tested compiling LEDE with musl 1.1.18 (using the patch here plus the 1.1.18 version bump). And I cleaned the whole toolchain. At the first glance LEDE r5217-098afa1e1b compiled with 1.1.18 booted ok and got normally a DHCP wan address, hostapd started etc.. So, 1.1.18 looks ok so far.
On 11/01/2017 12:15 PM, Hannu Nyman wrote: > At the first glance LEDE r5217-098afa1e1b compiled with 1.1.18 booted ok and > got normally a DHCP wan address, hostapd started etc.. Excuse me what?! "LEDE r5217-098afa1e1b"? Why does that look like a "release 5217" and a SHA prefix "098afa1e1b"? So what - does LEDE have two completely different versioning systems? Is LEDE switching over to the openwrt versioning system? From where comes the "r5217"? Is that "r5217" a strictly reproducible LEDE version? Somebody, please clue me in here.
On 19/10/17 23:41, Christian Lamparter wrote: > This patch updates musl to the latest 1.1.17 release. > > Rick Felker stated in his release note: " > This release fixes numerous bugs affecting visible behavior and > safety/internal consistency, including a stack-based buffer overflow > in dns parsing and multiple sources of invalid memory accesses that > may lead to crashes. See the release notes in WHATSNEW for details. > > Many new features have also been added, including deferred symbol > binding in the dynamic linker (RTLD_LAZY emulation), an option to > overrid argv[0] when running ldso to execute a program, support for > starting new sessions via posix_spawn (POSIX_SPAWN_SETSID, accepted > for standardization), and ability to query the active thread-local > locale (via _NL_LOCALE_NAME extension). Improvements in compatibility > with applications, build tools, and platforms have also been made. > " <http://www.openwall.com/lists/musl/2017/10/19/1> > > The stack-based buffer overflow in dns parsing can be mitigated by: > "running a caching nameserver on localhost and pointing resolv.conf > to 127.0.0.1." <http://www.openwall.com/lists/musl/2017/10/19/2> > Which is the case on the default LEDE installation (dnsmasq). > > Signed-off-by: Christian Lamparter <chunkeey@gmail.com> > --- > toolchain/musl/common.mk | 6 +++--- > toolchain/musl/patches/900-iconv_size_hack.patch | 4 ++-- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk > index 0a45828f79..4c4e5b47ae 100644 > --- a/toolchain/musl/common.mk > +++ b/toolchain/musl/common.mk > @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk > include $(INCLUDE_DIR)/target.mk > > PKG_NAME:=musl > -PKG_VERSION:=1.1.16 > +PKG_VERSION:=1.1.17 > PKG_RELEASE=1 > > PKG_SOURCE_PROTO:=git > PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) > -PKG_SOURCE_VERSION:=5f7efb87a28a311ad377dd26adf53715dedb096d > -PKG_MIRROR_HASH:=da18ef24f270e5cae6bc4c440479da17bec1949ae5a1bc990352ca04f24c4378 > +PKG_SOURCE_VERSION:=2cd663fb2d576d590a08c1e40386c07b378d5ad6 > +PKG_MIRROR_HASH:=e3140faaa9aff51c4f56f36c15d677265a5bed39aa6d9ab5d252f1c49b7c13ca > PKG_SOURCE_URL:=git://git.musl-libc.org/musl > PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz > > diff --git a/toolchain/musl/patches/900-iconv_size_hack.patch b/toolchain/musl/patches/900-iconv_size_hack.patch > index 343915fb06..cfbb7ee5f7 100644 > --- a/toolchain/musl/patches/900-iconv_size_hack.patch > +++ b/toolchain/musl/patches/900-iconv_size_hack.patch > @@ -32,7 +32,7 @@ > > static int fuzzycmp(const unsigned char *a, const unsigned char *b) > { > -@@ -216,6 +220,7 @@ size_t iconv(iconv_t cd0, char **restric > +@@ -224,6 +228,7 @@ size_t iconv(iconv_t cd0, char **restric > c = ((c-0xd7c0)<<10) + (d-0xdc00); > } > break; > @@ -47,7 +47,7 @@ > +#endif > default: > if (c < 128+type) break; > - c -= 128+type; > + c = legacy_map(map, c); > --- a/src/locale/codepages.h > +++ b/src/locale/codepages.h > @@ -118,6 +118,7 @@ Hi, 1.1.18 is out, we we go directly to that version please ? John
On 2017-11-06 14:46, John Crispin wrote: > Hi, > > 1.1.18 is out, we we go directly to that version please ?I've already queued a commit that updates to 1.1.18 in my staging tree. - Felix
On the topic of version numbers of the form "LEDE r5217-098afa1e1b" about which I am clueless, there is some discussion about the challenge of relating git hash numbers and "release" version numbers: Point releases for the GNU C Library October 16, 2017 https://lwn.net/Articles/736429/#Comments and then: [RFE] Add minimal universal release management capabilities to GIT 20 Oct 2017 https://public-inbox.org/git/1290947539.4254.1508496039812.JavaMail.zimbra@laposte.net/ Still, this is me again ranting about a problem which has no simple one solution. Food for thought... At one extreme, the linux kernel development uses a manual process to create formal development releases from a git repository. On the other extreme, the GNU C Library (glibc) project generally refuses to provide development releases, or even bug fix releases, between its official releases. Parenthetically, I notice that those two projects were perhaps the antithetical archetypes for "The Cathedral and the Bazaar" development models. Even though both projects use git now, they use it differently. LEDE is even more difficult, because it is not just one "package", but a construction of many packages.
On Monday, November 6, 2017 2:48:56 PM CET Felix Fietkau wrote: > On 2017-11-06 14:46, John Crispin wrote: > > Hi, > > > > 1.1.18 is out, we we go directly to that version please ? > I've already queued a commit that updates to 1.1.18 in my staging tree. > Yeah, go for it.
These version numbers are used between releases, the part after the - is enough of the git commit id (it's hash) for you to identify it. The r# gives you an idea if it's newer or older than another one (since git hashes don't give you that info) nightly builds are not point releases, so they should not be given point release IDs, they are automatic snapshots taken each night. The Linux kernel project releases a new release candidate every two weeks, but there are people doing nightly builds directly from git, they don't bother with the r## and just use the git hash. LEDE makes fewer official release candidates and the nightly snapshots are just that. David Lang
On 11/06/2017 09:01 AM, David Lang wrote:
> These version numbers are used between releases, the part after the - is enough of the git commit id (it's hash) for you to identify it. The r# gives you an idea if it's newer or older than another one (since git hashes don't give you that info)
Thanks for that David! How are the r#'s known? Are they simply incremented with every git commit? And they would apply to only one particular branch? I see two "heads", "master" and "lede-17.01". Do the r#'s apply to only one of those? Or, are "master" and "lede-17.01" guaranteed to not be parallel branches?
17.01 is pointer to a particular commit on the master branch I haven't looked at the specific method used for the r# generation, but I think it's incremented daily
David Lang <david@lang.hm> writes: > 17.01 is pointer to a particular commit on the master branch > > I haven't looked at the specific method used for the r# generation, > but I think it's incremented daily No, it counts commits. See scripts/getver.sh The method was discussed when the current scheme was commited. Search the list archive. Bjørn
On 11/07/2017 07:23 AM, David Lang wrote: > 17.01 is pointer to a particular commit on the master branch > > I haven't looked at the specific method used for the r# generation, but I > think it's incremented daily r# is the number of commits since the "reboot" tag. If your local branch (e.g. "master") has a upstream branch (e.g. "origin/master"), it will use number and commit ID of the last common commit of both branches, and add the number of local commits with a + (e.g. "r4601+95-1ab227d688" - the last common commit is 1ab227d688, 4601 after "reboot", and there are 95 local commits that aren't upstream). Basically, we tried to mimic the "revision ID" SVN provided for the old OpenWrt trunk, adding some extra information provided by git. You can look at the generation of this ID in scripts/getver.sh. At the moment, getver.sh doesn't distinguish between the master and lede-17.01 branches, so if you're unsure what branch an image is based on, you need to look up the commit ID. There have been a few attempts to improve this ( http://patchwork.ozlabs.org/patch/779410/ , http://patchwork.ozlabs.org/patch/785975/ ), but there is no decision how we want to handle this so far. For master commits, you can conveniently use the r# numbers on git.lede-project.org to link to commits, e.g. https://git.lede-project.org/r4601 . Matthias
On 11/06/2017 11:44 PM, Matthias Schiffer wrote: > r# is the number of commits since the "reboot" tag. If your local branch > (e.g. "master") has a upstream branch (e.g. "origin/master"), it will use > number and commit ID of the last common commit of both branches, and add > the number of local commits with a + (e.g. "r4601+95-1ab227d688" - the last > common commit is 1ab227d688, 4601 after "reboot", and there are 95 local > commits that aren't upstream). Thanks Matthias, that helps a lot. I also found some help with making sense of the git lingo, for anyone that has not already played with this: Visualizing Git Concepts with D3 https://onlywei.github.io/explain-git-with-d3/ It's an interactive visual learning aid. > Basically, we tried to mimic the "revision > ID" SVN provided for the old OpenWrt trunk, adding some extra information > provided by git. Ha! So there *was* an element of the OpenWrt revision numbering! I'm tempted to ask if there is not some value, then, in a LEDE revision numbering that would look like "lede-17.01.r4601"? Would that not be a precise, and monotonic, version declaration, no matter whether it was an "official" release, or a nightly, or even some random snapshot? Hmm - and then, isn't a designation of the form "lede r5217" completely unambiguous, other than not providing a branch name, to say, for instance, that it is, or is not, an "official release"? So then, LEDE does not run parallel development branches in the main git repository, and simply designates certain development snapshots as "official releases"?
On 11/07/2017 03:25 PM, James Feeney wrote: > On 11/06/2017 11:44 PM, Matthias Schiffer wrote: >> r# is the number of commits since the "reboot" tag. If your local branch >> (e.g. "master") has a upstream branch (e.g. "origin/master"), it will use >> number and commit ID of the last common commit of both branches, and add >> the number of local commits with a + (e.g. "r4601+95-1ab227d688" - the last >> common commit is 1ab227d688, 4601 after "reboot", and there are 95 local >> commits that aren't upstream). > > Thanks Matthias, that helps a lot. I also found some help with making sense of the git lingo, for anyone that has not already played with this: > > Visualizing Git Concepts with D3 > https://onlywei.github.io/explain-git-with-d3/ > > It's an interactive visual learning aid. > >> Basically, we tried to mimic the "revision >> ID" SVN provided for the old OpenWrt trunk, adding some extra information >> provided by git. > > Ha! So there *was* an element of the OpenWrt revision numbering! > > I'm tempted to ask if there is not some value, then, in a LEDE revision numbering that would look like "lede-17.01.r4601"? Would that not be a precise, and monotonic, version declaration, no matter whether it was an "official" release, or a nightly, or even some random snapshot? > > Hmm - and then, isn't a designation of the form "lede r5217" completely unambiguous, other than not providing a branch name, to say, for instance, that it is, or is not, an "official release"? > > So then, LEDE does not run parallel development branches in the main git repository, and simply designates certain development snapshots as "official releases"? No, we have two official branches: master (active development for the next major release), and lede-17.01 (forked from master shortly before the 17.01 release; only bugfixes and other "small" changes are backported from master; base for 17.01.x maintenance releases). Fixing our revision numbering to include the branch name to make this more or less unambiguous is the intent of the two patches I linked. The commit ID should still be included in this revision number (e.g. lede-17.01-r9000-abcdef), as developers could still set the "upstream branch" to an inofficial branch without changing the branch name, thus making the number ambiguous again. Matthias
Matthias Schiffer <mschiffer@universe-factory.net> writes: > Fixing our revision numbering to include the branch name to make this more > or less unambiguous is the intent of the two patches I linked. The commit > ID should still be included in this revision number (e.g. > lede-17.01-r9000-abcdef), as developers could still set the "upstream > branch" to an inofficial branch without changing the branch name, thus > making the number ambiguous again. FWIW, if we are going to have this discussion again: I still think the output of 'git describe' is a simple, good and precise description of the "current revision". All releases will then be named by their tags. Other revisions are named relative to their most current tag, but including the exact commit hash so that there is no ambiguity even with multiple branches. For example: The current lede-17.01 branch HEAD is: bjorn@canardo:/usr/local/src/lede$ git describe origin/lede-17.01 v17.01.4-20-g6b6578feec74 The 17.01 release tags are not part of the master branch, so that one is still named relative to 'reboot': bjorn@canardo:/usr/local/src/lede$ git describe origin/master reboot-5279-g2b6facc8d4b3 The last commit before the 17.01.0 release was named: bjorn@canardo:/usr/local/src/lede$ git describe v17.01.0^ reboot-3205-g59508e309e91 As you can see, there is a lot in common with the current scheme for the master branch, where the base tag is 'reboot'. But I believe the scheme is better because it a) works with more than one branch b) scales even when there are a million commits after 'reboot' c) nicely describes the offset from the last release for e.g. the stable branch d) nicely compresses to a simple tag name for any tagged release e) precisely identifies the revision even for branches with local commits I don't see the point of reinventing the wheel by counting commits the way scripts/getver.sh does, blindly assuming a single branch, and special casing release versions by using a separate file to hold the version for those. Bjørn
On 11/07/2017 07:43 AM, Matthias Schiffer wrote: > No, we have two official branches: master (active development for the next > major release), and lede-17.01 (forked from master shortly before the 17.01 > release; only bugfixes and other "small" changes are backported from > master; base for 17.01.x maintenance releases). Aha! That's really useful. I looked for some help with git visualization: Visualizing branch topology in git https://stackoverflow.com/questions/1838873/visualizing-branch-topology-in-git Then: git clone git://git.lede-project.org/source.git cd source git log --graph --all --pretty=fuller --simplify-by-decoration Also useful: git-big-picture -i -m -f pdf -v okular
On 11/07/2017 06:20 PM, Bjørn Mork wrote: > Matthias Schiffer <mschiffer@universe-factory.net> writes: > >> Fixing our revision numbering to include the branch name to make this more >> or less unambiguous is the intent of the two patches I linked. The commit >> ID should still be included in this revision number (e.g. >> lede-17.01-r9000-abcdef), as developers could still set the "upstream >> branch" to an inofficial branch without changing the branch name, thus >> making the number ambiguous again. > > FWIW, if we are going to have this discussion again: I still think the > output of 'git describe' is a simple, good and precise description of the > "current revision". > > All releases will then be named by their tags. Other revisions are > named relative to their most current tag, but including the exact commit > hash so that there is no ambiguity even with multiple branches. > > For example: > > The current lede-17.01 branch HEAD is: > > bjorn@canardo:/usr/local/src/lede$ git describe origin/lede-17.01 > v17.01.4-20-g6b6578feec74 > > The 17.01 release tags are not part of the master branch, so that one is > still named relative to 'reboot': > > bjorn@canardo:/usr/local/src/lede$ git describe origin/master > reboot-5279-g2b6facc8d4b3 > > The last commit before the 17.01.0 release was named: > > bjorn@canardo:/usr/local/src/lede$ git describe v17.01.0^ > reboot-3205-g59508e309e91 > > > As you can see, there is a lot in common with the current scheme for the > master branch, where the base tag is 'reboot'. But I believe the scheme > is better because it > a) works with more than one branch > b) scales even when there are a million commits after 'reboot' > c) nicely describes the offset from the last release for e.g. the > stable branch > d) nicely compresses to a simple tag name for any tagged release > e) precisely identifies the revision even for branches with local > commits > > I don't see the point of reinventing the wheel by counting commits the > way scripts/getver.sh does, blindly assuming a single branch, and > special casing release versions by using a separate file to hold the > version for those. > > > > Bjørn > I pretty much agree. But if we use `git describe`, we should probably introduce weekly "ridiculous count" tags in the master like Linux has. The way getver.sh bases its number and commit ID on the last common commit with the upstream branch seems like a good idea to me, it's more useful than having a local commit ID in the revision number (especially for bug reports). Combining this with `git describe` would be easy. While not directy related, I'm also not really a fan of our linear history, as merge commits for feature branches/patchsets (possibly including cover letters) can also contain useful information about the development history. Well, just some food for thought, based on my personal preferences. Our current versioning scheme and linear history also work well, so unless other developers have similar ideas, let's just continue with that for now. Matthias
On 2017-11-07 22:17, Matthias Schiffer wrote: > On 11/07/2017 06:20 PM, Bjørn Mork wrote: >> Matthias Schiffer <mschiffer@universe-factory.net> writes: >> >>> Fixing our revision numbering to include the branch name to make this >>> more >>> or less unambiguous is the intent of the two patches I linked. The >>> commit >>> ID should still be included in this revision number (e.g. >>> lede-17.01-r9000-abcdef), as developers could still set the "upstream >>> branch" to an inofficial branch without changing the branch name, >>> thus >>> making the number ambiguous again. >> >> FWIW, if we are going to have this discussion again: I still think >> the >> output of 'git describe' is a simple, good and precise description of >> the >> "current revision". >> >> All releases will then be named by their tags. Other revisions are >> named relative to their most current tag, but including the exact >> commit >> hash so that there is no ambiguity even with multiple branches. >> >> For example: >> >> The current lede-17.01 branch HEAD is: >> >> bjorn@canardo:/usr/local/src/lede$ git describe origin/lede-17.01 >> v17.01.4-20-g6b6578feec74 >> >> The 17.01 release tags are not part of the master branch, so that one >> is >> still named relative to 'reboot': >> >> bjorn@canardo:/usr/local/src/lede$ git describe origin/master >> reboot-5279-g2b6facc8d4b3 >> >> The last commit before the 17.01.0 release was named: >> >> bjorn@canardo:/usr/local/src/lede$ git describe v17.01.0^ >> reboot-3205-g59508e309e91 >> >> >> As you can see, there is a lot in common with the current scheme for >> the >> master branch, where the base tag is 'reboot'. But I believe the >> scheme >> is better because it >> a) works with more than one branch >> b) scales even when there are a million commits after 'reboot' >> c) nicely describes the offset from the last release for e.g. the >> stable branch >> d) nicely compresses to a simple tag name for any tagged release >> e) precisely identifies the revision even for branches with local >> commits >> >> I don't see the point of reinventing the wheel by counting commits the >> way scripts/getver.sh does, blindly assuming a single branch, and >> special casing release versions by using a separate file to hold the >> version for those. >> >> >> >> Bjørn >> > > I pretty much agree. But if we use `git describe`, we should probably > introduce weekly "ridiculous count" tags in the master like Linux has. > > The way getver.sh bases its number and commit ID on the last common > commit > with the upstream branch seems like a good idea to me, it's more useful > than having a local commit ID in the revision number (especially for > bug > reports). Combining this with `git describe` would be easy. > > While not directy related, I'm also not really a fan of our linear > history, > as merge commits for feature branches/patchsets (possibly including > cover > letters) can also contain useful information about the development > history. > > Well, just some food for thought, based on my personal preferences. Our > current versioning scheme and linear history also work well, so unless > other developers have similar ideas, let's just continue with that for > now. > I fully agree with Bjorn. I would add `--dirty` to see if the reported version has local uncommited changes. Also I would keep one branch for all releases. That is releases are tagged and merged back from master. Regards, Roman
diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk index 0a45828f79..4c4e5b47ae 100644 --- a/toolchain/musl/common.mk +++ b/toolchain/musl/common.mk @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/target.mk PKG_NAME:=musl -PKG_VERSION:=1.1.16 +PKG_VERSION:=1.1.17 PKG_RELEASE=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) -PKG_SOURCE_VERSION:=5f7efb87a28a311ad377dd26adf53715dedb096d -PKG_MIRROR_HASH:=da18ef24f270e5cae6bc4c440479da17bec1949ae5a1bc990352ca04f24c4378 +PKG_SOURCE_VERSION:=2cd663fb2d576d590a08c1e40386c07b378d5ad6 +PKG_MIRROR_HASH:=e3140faaa9aff51c4f56f36c15d677265a5bed39aa6d9ab5d252f1c49b7c13ca PKG_SOURCE_URL:=git://git.musl-libc.org/musl PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz diff --git a/toolchain/musl/patches/900-iconv_size_hack.patch b/toolchain/musl/patches/900-iconv_size_hack.patch index 343915fb06..cfbb7ee5f7 100644 --- a/toolchain/musl/patches/900-iconv_size_hack.patch +++ b/toolchain/musl/patches/900-iconv_size_hack.patch @@ -32,7 +32,7 @@ static int fuzzycmp(const unsigned char *a, const unsigned char *b) { -@@ -216,6 +220,7 @@ size_t iconv(iconv_t cd0, char **restric +@@ -224,6 +228,7 @@ size_t iconv(iconv_t cd0, char **restric c = ((c-0xd7c0)<<10) + (d-0xdc00); } break; @@ -47,7 +47,7 @@ +#endif default: if (c < 128+type) break; - c -= 128+type; + c = legacy_map(map, c); --- a/src/locale/codepages.h +++ b/src/locale/codepages.h @@ -118,6 +118,7 @@
This patch updates musl to the latest 1.1.17 release. Rick Felker stated in his release note: " This release fixes numerous bugs affecting visible behavior and safety/internal consistency, including a stack-based buffer overflow in dns parsing and multiple sources of invalid memory accesses that may lead to crashes. See the release notes in WHATSNEW for details. Many new features have also been added, including deferred symbol binding in the dynamic linker (RTLD_LAZY emulation), an option to overrid argv[0] when running ldso to execute a program, support for starting new sessions via posix_spawn (POSIX_SPAWN_SETSID, accepted for standardization), and ability to query the active thread-local locale (via _NL_LOCALE_NAME extension). Improvements in compatibility with applications, build tools, and platforms have also been made. " <http://www.openwall.com/lists/musl/2017/10/19/1> The stack-based buffer overflow in dns parsing can be mitigated by: "running a caching nameserver on localhost and pointing resolv.conf to 127.0.0.1." <http://www.openwall.com/lists/musl/2017/10/19/2> Which is the case on the default LEDE installation (dnsmasq). Signed-off-by: Christian Lamparter <chunkeey@gmail.com> --- toolchain/musl/common.mk | 6 +++--- toolchain/musl/patches/900-iconv_size_hack.patch | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-)