Opened 21 months ago
Closed 20 months ago
#18331 closed enhancement (fixed)
Update qtwebengine-5.15.15 to 2023-07-20
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | elevated | Milestone: | 12.0 |
| Component: | BOOK | Version: | git |
| Severity: | normal | Keywords: | |
| Cc: |
Description ¶
Following the release of qtwebengine-6.5.2 on 19th July, the various 87-based fixes from qtwebengine chromium were merged intothe5.15.15 branch on 2023-07-20.
This gives me hope that 87-based will continue to receive fixes until kde finally gets to Qt6.
Change History (7)
comment:1 by , 20 months ago
| Milestone: | 11.4 → 12.0 |
|---|
follow-up: 4 comment:2 by , 20 months ago
For the moment I'm calling this 5.15.15 - I guess that the next release (if any) will be called 5.15.16 and come just after the next release of whichever is the current qt6 version.
Tested on a system from June, I note that the timing went out to 73 SBU, but that was with NINJAJOBS=4 on an 8-core haswell, I suspect I took 4 cores offline for the previous measurement and let ninja use N+2. My SBU is, not unexpectedly, a bit longer on newer builds.
I don't have a system with the current toolchain, so no idea if this will build with latest binutils, glib, ffmpeg.
comment:3 by , 20 months ago
Backported CVE fixes in this version, all are rated High:
CVE-2023-2721 Use after free in Navigation
CVE-2023-2931 Use after free in PDF
CVE-2023-2932 Use after free in PDF
CVE-2023-2932 Use after free in PDF
CVE-2023-2933 Use after free in PDF
CVE-2023-2935 Type confusion in V8
CVE-2023-3079 Type confusion in V8
CVE-2023-3216 Type confusion in V8
comment:4 by , 20 months ago
Replying to ken@…:
Tested on a system from June, I note that the timing went out to 73 SBU, but that was with NINJAJOBS=4 on an 8-core haswell, I suspect I took 4 cores offline for the previous measurement and let ninja use N+2. My SBU is, not unexpectedly, a bit longer on newer builds.
Now I look at what is in the book, the timing was 75 SBU, so 73 is within the expected margin of error for a slightly newer LFS.
comment:5 by , 20 months ago
For these longer packages please use -j8 for timing. Currently that's in place for nodejs, rust, gcc, llvm, libreoffice, inkscape. My rule of thumb is that if it takes more than 5 SBU with the number of cores we are currently using, go to -j8.
I will be doing lfs-12.0-rc1 next week with all tests and will use -j4 for everything.
comment:6 by , 20 months ago
I've just pushed with -j4. I had an initial figure from accidentally building as -j8, but the box was in swap (too many things open) so that is unreliable.
Updated in sha:ebccba383d 11.3-1269
comment:7 by , 20 months ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Security Advisory SA 11.3-070 created.
Milestone renamed