- User Since
- Dec 26 2016, 1:01 PM (77 w, 1 d)
Mon, Jun 18
Sat, Jun 16
Update summary & test plan
Update to 4.0.2
Fri, Jun 15
Update to 67.0.3396.87
Initial support for headless chromium, see here
Thanks @DataDrake, i got a bit ahead of myself when I saw it marked as wishlist but didn't check if it was moved to 'Accepted to Inclusion'.
Thu, Jun 14
Wed, Jun 13
Resolved by 797464020628. For any issues please open a separate task and I will resolve them as best I can within the limitations of the project.
Resolved by a5f40b0b7184
Sat, Jun 9
They updated the .desktop file for the 2.7.1 release, the sed hacks shouldn't be necessary anymore, see here
Fri, Jun 8
No movement on the api key situation which is the blocker. Potentially could ask them myself for keys which are allowed to distribute so we wouldn't have to put in new infrastructure to hide them but I'm only an half-official member of the team so it doesn't seem right that I should.
Update to 67.0.3396.79 latest stable
Re-enable experiantal optional VAAPI HW decoding
Thu, Jun 7
Feel free to reopen if you continue to have the problem
Still waiting for a new release from upstream. Good news it that the master branch seems to support newer cython versions, see here
Fri, Jun 1
Thu, May 31
Disable use of systemflags simply because i can't get ccache to work with this questionable build system
Latest current LTS is 4.14 which dbus-broker supports FWIW, if we were to upgrade our lts kernel (I'm not sure if there's any blockers on that or if ikey simply hasn't gotten around to it). Regardless, even with some invisible performance enchantments we risk weird breakage by implementing this. This is definitely tempting to hack on though.
Update to 67.0.3396.62
Rebase and update patches as required
Build with system flags
Adjust for upstream widevine changes
Wed, May 30
We may be needing this patch for llvm. Should install the missing headers if i'm not wrong.
Tue, May 29
Could you justify the use of libcap vs libpcap-ng ?
You need the change the source back to git as upstream doesn't configure the release version in the automatic tarballs create by github.
volume_key 0.3.10 has been released which should support cryptsetup 2.0.0 without patches. If that is the case it probably makes sense to abandon this patch for a new one.
Sun, May 27
It's a problem with linux 4.16 afaik with CRNG.