Hello, I updated the patch disabling openh264: https://salsa.debian.org/mimi89999/chromium/-/blob/master/debian/patches/disable/openh264.patch
I was able to build Chromium with proprietary codec support, but without openh264. Michel Le Bihan On Mon, 14 Dec 2020 21:04:00 +0100 Michel Le Bihan <mic...@lebihan.pl> wrote: > Hello, > > > I suspect that debian's libvpx might need to be build with > experimental features enabled (similar to a previous bug report), in > order to include the absent header files. > > This will build the lib, but the header isn't correctly exported. They > don't export the header file for that and the internal header used by > Chromium requires many other internal headers. > > > Are you sure that fixes/sequence-point.patch is necessary? I don't > recall getting any warnings related to this when compiling. > > I don't know. I don't see the warning mentioned in the commit without > that patch, but I also don't see the commit in Chromium that could > change that. > > > Looking at the last couple of commits for the file affected by the > ozone problem [1], it appears to be already fixed upstream. > > Great! That will make one less patch to update on next release! > > I'm still missing 4 patches: > buster/icu63: Without that one it might be difficult to get the update > in Buster > system/vpx: It's better to use system libs it it isn't too difficult. > There is one commit in Chromium introducing the usage of that > experimental feature. Maybe the patch could revert it? > system/harfbuzz: I didn't investigate what's wrong with it. Just used > in tree version. > A patch for proprietary codecs + system ffmpeg. > > Maybe more will be needed for Lintian warnings and errors. > > Does anybody have any of the mentioned patches updated/written? It > would avoid duplicate work. I know those are the most difficult patches > to update. > > Michel Le Bihan > > >
