glibc: bump to 2.26
Get series with b4
b4 am 20171016162519.GC2862@scaerVersions newest first · linked by author and title
- v3 Latest6 of 7 patches 0 repliesNew
- v25 of 11 patches 0 repliesSuperseded
6 of 7 patches are in this archive. The cover letter announces 7.
Patches in v3 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/7 | package/gcc: fix build issue with glibc 2.26 | +0 | 0 replies | |
| 2/7 | package/gcc: fix build issue with glibc 2.26 | +0 | 0 replies | |
| 3/7 | package/glibc: needs kernel headers >= 3.10 on powerpc64le | +0 | 0 replies | |
| 4/7 | package/gcc: enable float128 on powerpc64le with glibc >= 2.26 toolchains | +0 | 1 reply | |
| 5/7 | package/diffutils: disable getopt_long replacement with glibc | +0 | 0 replies | |
| 6/7 | package/flex: disable reallocarray | +0 | 1 reply |
Reviews trailers per patch
5 of 6 patches have a Reviewed-by or Acked-by.
| Patch | Yann E. MORIN |
|---|---|
| 1/7 | R-b |
| 2/7 | R-b |
| 3/7 | R-b |
| 4/7 | R-b |
| 5/7 | R-b |
| 6/7 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [Buildroot] [PATCH v3 0/7] glibc: bump to 2.26
Arnout, All,
On 2017-09-27 23:12 +0200, Arnout Vandecappelle spake thusly:
Quoted 7 lines · Romain Naour
Quoted 1 line
Let's hope that glibc 2.26.1 will be released soon :)
As discussed on IRC:
Apparently there won't be a glibc 2.26.1. It's up to distros to pick a git
commit to release.
Yep, this is just silly... :-(
Quoted 4 lines
So we have the choice to either keep a lot of patches in Buildroot, or use a git download instead of a tarball. The latter has the disadvantage of having a silly version "number" (the sha1), and that git downloads are generally much slower.
If we want a slightly less-silly-looking version, we could use something like:
glibc-2.26-43-gfdf58eb
whichh means the sha1 'fdf58eb' that is '43' commits after the 'glibc-2.26' tag. But we have to be careful about shortening the sha1, to avoid collisions. I would say that we stay with the full sha1.
It is pretty easy to generate such a version string:
git describe --match 'glibc-*' --abbrev=12 origin/release/2.26/master
Quoted 1 line
For now, we have those 6 patches in Buildroot. This may change in the future.
I would say that we should switch to using the 2.26/master branch from upstream, because we don;t have the bandwidth to assess whether we need/want to backport individual patches.
If upstream commits on the maintenance branch, it means that it is a fix. And we want fixes, whatever they fix: functionality or security.
So I'd say we should switch to git. The repo is even accessible through https (although it is not documented): https://sourceware.org/git/glibc.git
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'