GPU: AMD RX5700XT
Games = all. Even steam big picture flickers when the screen in Freesync mode. So maybe this is something that triggers when an app tries to take fullscreen. Compositor enabled/disabled changes nothing.

Same behaviour while gaming ? intense flickering ?

Better summary

Yes ! The latest release is from less than 24 hours ago. I had to modify the package to get it built but haven't run all the test plans yet. Anyway this should be in unstable before Friday's sync.

Guess I was too enthusiastic about this.

Damn I wad pretty sure I read somewhere on github, amdgpu-pro was not needed anymore. I'll do a quick roundup. Vaapi here we are again

I'll check that ASAP.
Anyway you can merge this into unstable and if effectively I need to remove libglvnd I'll make sure this happen when I'll update mangohud. It should happen soon enough.

Now everything is one package. I used to rename mangohud.x86 to mangohud.i686 to match solus scheme, but in order to make sure there is a full 32 bits compatibily I let the actual naming. There is a hardcoded reference to mangohud.x86 in mangohud (x86_64) which doesn't change a thing when in 64 bits but will go bork if full 32 which is not possible anymore since everything is in 1 package.
?

Requested change about how patterns are handled

Last update before release was supposed to be small it ended rather long.

• added maintainers file
• update to latest version, released 6 day ago
• remove /usr/bin/mangohud.i686 binary as it is not required anymore but still created after compile

New version and test plan for 32bits mangohud. Removed unused files

@DataDrake Can do. Let's just clarify some things before we start another revision.
The only diff between the 64 and 64 bit exec is this

< LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/lib32/mangohud"
---
> LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/lib64/mangohud"

Many updates since first review. I've playing with mangohud package on my PC for some time now and tested it on many games. Still not convinced about the mangohud.i686 in /usr/bin

The project evolved pretty quickly, the latest release are not "pre-release" anymore
version 0.3.1

Update mangohud to 0.3.1. This include new feature notably shell scripts for 32 and 64 bits. I rename 32 bits binary to .i686 but not sure how this fit in the ecosystem

Integration with patterns ! And now it makes much more sense.
I didn't add a conf file for 32bit as there is no need of having one. Even for 64 bits. It's just here for people to have a template if the feel the need to use it. Ofc, I can modify this if you're not ok with this.

So um... mangohud.json is installed everytime ninja_install passes. I didn't find a way via package tools to force the file to be associated with the 32bits libs. :/

Update file path and lib path

Ok I checked icd.d related vulkan directory and you're correct for i686 and x86_64.
I 'll also checkout tomorrow if I can pack the i686 jsonfile with the 32 bit subpackage.

I started to check for mangohud32/64.json files and I have a package.yml version that does it. However, it relies on some bash posted below.
I believe this is far from what Ikey proposed with a different package for the json file. But I really have no clue how to handle this.
Side note, I use mangohud everyday with an incorrect json file and it works well. I wonder where it's used.

Some update on this:
I added a configuration file for mangohud in /usr/share. While this is totally not mandatory for manghud to work or configure (env vars are ok) I find it nice to have it somewhere.
Also the name is now lowercase

Fix things reported by coreteam. Also remove libglvnd as dependency after speaking with mango dev team as this is not useful

@Girtablulu I see your comments and this will be corrected soon but I can't use the source tar here because the building process involve git submodule to fetch a specific git commit of imGui

So simple...

Thanks Ikey for providing Solus support upstream.
I gave a quick look around packaging this morning and for now, I don't know how to handle imgGui which is called via a git submodule command in the build.

Yup, planned on packaging this thing too but better be sure the core team gives approval first :)

Also interested in this

Also, the license model changed for this version. It's now Apache License version 2.0 with llvm exception

Nice. At the moment I use containerd which does kind of the same but podman looks more polished

Updating D2682: Update to version 1.8 and switch to python3

Yes kind of.
Never used surfraw. I'd say the biggest difference is ddgr focus on leveraging DuckDuckgo functions while surfraw is a global command line researcher.
ddgr seems more user friendly too.

Sorry messed up. Wanted to test arcanist but did not intend to send an incomplete package.
Correct version is here: https://dev.solus-project.com/D2682

Allow me some time to confirm or invalidate this. I didn't have time to test with recent Solus updates.

Neat : D langage accepted for inclusion in GCC

Would be nice if users had opportunity to choose if they need web plugin functionality or not themselves.

Packager of this thing here.
If I remember correctly, decision was to not include npapi because it's removed or soon to be removed form recent browser (aka: chrome, firefox)
You can download and launch the .jlnp files.

Did something change with the last update ??

When forcing to use Xorg session , Gnome manage to launch properly. The error is still there when it tries to launch wayland and failed, then x-session.
I only have a small bug when the laptop is docked and the display forward to a dual screen setup. Only the login screen background appears.

Nothing to do with the display manager - this is the error. What graphics do you have?

Yep, should have mentionned I used /etc/kernel/cmdline instead of /etc/default/grub.
Need to reboot to confirm this all work well.

Note: The clr-boot-manager update broke keyboard again. You need to re add your vconsole.keymap

I just tested this and this is pretty useful GUI.
If this is accepted for inclusion, I'll package it.

Now that I have the correct workflow there is no reason not to use it. Open new tasks and stuff.

It have been recently introduced to me that you should NEVER change tags.
So... I'm gonna change tags (:D) to go back to previous and correct state.

1 - Noted. Will do when point 2 is ok.
3 - Yes and that's why I was wandering if there is a golang macro (didn't find one). And as I said, I used docker and hugo as example and one of them is using pre-built version.
hugo link in package leads to a binary but not in docker.
We have something inconsistant here.

Hi
Never tried packaging a go software. But why did I choose a web server. Erf...
For the package team this is what I did

I made a new version with only pkgconfig(nettle) and pass only bindir arg to %autogen.
This seems to be ok.

Also libnettle-devel wich is required includes pkgconfig(hogweed).
So Do I have to put

• pkgconfig(nettle)
• pkgconfig(hogweed)

or only

• pkgconfig(nettle)

I gave a quick look over this.
When trying to compil icedtea-web it requires a "mozilla-plugin" package.
From what I understand, after changing names many times this "package" or "headers" are now in NPAPI. Problem is: Chronium and Chrome are not using this anymore and Firefox plans to stop NPAPI soon.
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Anyway didn't try with NPAPI headers yet but this could be a future problem, I'm not sure icedtea-web plan to evolve with the new API chrome et Firefox are using.

if you set your keyboard in a layout diffrent from English, you fall in this case.
https://dev.solus-project.com/T1216

It works ! Tried this morning.
Edited grub at boot time and add vconsole.keymap.

Don't know if it's doable to load local keyboard before passphrase is asked. It seems encryption is on a pretty early phase.

+1 here.
Keyboard layout in french during install but when the passphrase is asked the keyboard layout is in English.

Delivered

Ok this is done. Should I give you a new patch following my commit message witch is something like "Better formating"
Or redo the Initial commit patch ??

In T480#7689, @Raccoon wrote:

I could be misunderstanding what you're trying to accomplish here, but couldn't you just have Kodi and Steam opened in separate workspaces and then switch between them using 'ctrl'+'alt'+'left'/'right'?

Yep I know, but never found 1.08 even in up to date distro (Fedora 24 and arch)
It's up to you.