[LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

[Koen Vandeputte]

>> Yes,
>>
>> Main reason in that specific case was mainly for these 2 fixes:
>>
>> /9e01be6 fix signal masking race in pthread_create with priority (I use
>> lots of threading & thread priority in my app) //51bdcdc fix OOB reads in Xbyte_memmem (used by memmem() ) /
>>
> Hm? Are you now talking about something else? I remember seeing these
> commits listed in your musl update to 1.1.16+.
> <http://lists.infradead.org/pipermail/lede-dev/2017-October/009234.html>
>
> But Felix did the update musl to 1.1.18 on the 5th (I noticed that he had
> a patch queued). This update included the changes you listed, right?
>
I was indeed referring to that one, as a mere example where I proposed 
to bump to head, just like you propose now. (got superseded)
http://patchwork.ozlabs.org/patch/823135/

>> fwiw, my 2 cents:
>>
>> I try to carefully judge whether there's a good reason to bump head or
>> not, and I mostly wait for min 48 hrs to let the latest commits soak a bit.
> "waiting" around doesn't help in regression cases. I think this
> glob-regression is another case in point. The issue was discovered
> more than a week before 1.1.17 was released:
> <https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09180.html>
> and when I posted the request to move to 1.1.17 (again).
> But it only received the attention, once people started testing the new
> 1.1.17 and did bisections.
After Syrone's reply concerning the regression, we've immediately 
contacted the committer in a separate mail-thread to get in-depth asap :)
keep in mind the reply mentioned:

"when I update to c10bc61 powerpc{64}: fix MAP_NORESERVE and MAP_LOCKED in mman.h"

Which indicates it was not clear at that time which commit exactly 
caused it.
>
> Maybe a balanced solution would be to wait for 1 .. 2  tested-by's
> before pushing these to master?
> Great that you bring this up. So, did you test >this patch< already too?
> And if so, what's your verdict? Does it perform as expected on your cns3xxx?
> Can you please post a "tested-by" tag then?
I've added it to my daily build yesterday, and it's running on my stress 
setup currently. (9 boards: 6x cns3xxx & 3x imx6, all meshed up)
If all goes well, I'm more that happy to drop a tested-by within the 
next few hours (like I sometimes do for other people's patches too)

Feel free to do the same for mine ;)
>
> As for pushing to master: From most past experience, a patch usually sits
> in the patchwork queue for some time (a few days to months). Then one of
> the commiter adds it to his/her public staging tree and if all went well,
> the patch moves to master eventually.
>   
> Regards,
> Christian

Keep in mind that I'm defending your approach completely, as long as the 
reason to bump is valid (in general) :)

Koen