Implement PGO hints and improvements from
http://llvm.org/docs/HowToBuildWithPGO.html
https://github.com/llvm-mirror/llvm/blob/master/utils/collect_and_build_with_pgo.py

I have a working package for this, however, it requires JDK 9 or later without downloading their bundled Java. Several system packages still require openjdk 8 as we have packaged but we have no way to provide multiple java versions currently, see T6658.

i'll do a build without 32bit support to see if the symbols reappear first. I was hoping to avoid having to use emul32. Additionally, there is new documentation and a script for building PGO clang upstream which gives a few pointers.

Update to 70.0.3538.67
Rebuild against system icu
Usual new patches and rebasing to fix compile errors
Requires a newer harfbuzz

Not exactly happy with upstream with their changes, we might have to switch to repackaging the deb in future but this can go in for now. Such are electron apps. Thanks for figuring out the pain points.

This is a different piece of software different from kdeconnect meant for gnome based environments.

Poking @sunnyflunk for thoughts.

Fixup summary

patch is an empty file just fyi

Relevant bit from r's configure output after adding pkgconfig(tk) to builddeps. If someone has some time to take a look at this, something about our tcl/tk packages is broken.

checking for tclConfig.sh... no
checking for tclConfig.sh in library (sub)directories... /usr/lib64/tclConfig.sh
checking for tkConfig.sh... no
checking for tkConfig.sh in library (sub)directories... /usr/lib64/tkConfig.sh
checking tcl.h usability... yes
checking tcl.h presence... yes
checking for tcl.h... yes
checking tk.h usability... yes
checking tk.h presence... yes
checking for tk.h... yes
checking whether compiling/linking Tcl/Tk code works... no

Thank you so much for this, the api changes were a little too over my head.

widevine is nothing to do with ffmpeg though

You can install in unstable now via linux-tools-turbostat. You should be able install from unstable to stable here if you're using stable.

Cleanup the changelog please - remove mention of architectures which are not relevant such as ARM and avoiding citing specific bug report/pull request numbers.

Please cleanup the changelog - avoid citing specific numbers of bug report numbers or pull requests such as 'Closes #999 and others'. A slightly more detailed testplan would able be appreciated such as tested 'Microphone and Webcam input', 'Tested chat functionality', stuff like that

What's the situation with building this from source once again?

Re-opening since some things were rolled back

Have at it, the make package-electron has been replaced by by make electron-build and you'll likely need to modify the build scripts to not to build a rpm package see here

Dumb build hurdles to jump and electron apps, name a more iconic duo. Will have to checkout from commit 2907cd1.

They're using ssh submodules will have fork just to clone it with solbuild - so irritating.

Support for it comes in this commit - which isn't part of a stable release yet - could theoretically be backported (as there's an AUR package for it) but mileage may vary. Assigning to Josh since he maintains obs-studio but I would reckon his response would be - wait for a new stable release.

Updated the pam config to:

Alright to get this working install pam-u2f. Then run pamu2fcfg > ~/.config/Yubico/u2f_keys and press the button on your yubico key. Finally edit /etc/pam.d/system-auth and before auth required pam_unix.so, add

# Yubico Universal 2 Factor Auth from `pam-u2f` package
# Change `required` to `sufficient` to login without a password
auth required pam_u2f.so cue

That's the android app release. The linux application is still at 1.3.2 which is the currently packaged version.

Enabling sse3 will mean sdl games won't work on CPUs pre-2004/2005. I'm not sure if that would be acceptable. We generally use sse2 or avx2.

Assigning to Josh as he'll have the final say when performing the GNOME stack upgrade and will have to figure this out.

I don't like to block your work but I would say this is part of the T6971 upgrade. Additionally, we currently only support enchant1 and we've been opposed to packaging two different versions of enchant up to this point. The new gspell update seems to only support enchant2. There is a fairly complex dependency graph to update enchant to version 2. One of the main blockers is poedit which will require a gtk3 built version of wxwidgets to use a newer version of gtkspell (gtkspell3) which in turn, can be built against enchant 2. We did try to upgrade wxwidgets to gtk3 before (T5974) but there were too many bugs (mostly theming and display issues) and we rolled it back.

If the 32bit version of this package was not needed for steam games that would be highly-preferable - but somehow I doubt that's the case! :D

We need 32bit rust to update this, probably why it went under the radar for so long.

In T4612#134318, @livingsilver94 wrote:

Have a look at Fedora's patches for that.

I have this packaged but I would really like a regular user of netbeans to test and a long-time maintainer or tester to step foward. Additionally, there is some small annoyances with the packaging including windows, mac, arm jni libs which I have to filter out and remove.

Performed additional testing with bookworm, pantheon-files and midori

You probably need to add libgcrypt-devel to builddeps as it was removed from solbuild's base image.