If your GPU supports VP9 decoding (check via the support matrix here) can you install and run vdpauinfo and see if vp9 is supported?

Just an update on this, working on updating everything in eopkg info -c programming.python - especially core python items like python-setuptools, python-wheel, python-pytest to make sure everything is fully 3.7 ready. Validating things locally and pushing things one by one. Progress is slower than hoped for, as my hatred for python is growing by the minute.

Confirmed but should be reported here; https://github.com/getsolus/ypkg. For reference the offending commit is here. Feel free to to send a pull request there.

As an interim solution after suspend if you have no sound you can run;

I actually have the extract same motherboard as you can confirm this issue. I don't use sleep nowadays so didn't notice this. But, yeah. I'm pretty sure this wasn't an issue before.

What happens if you run: xrandr --setprovideroutputsource modesetting Intel then xrandr --auto after logging in with the intel driver installed?

Thanks @xulongwu4 for the help, that indeed did resolve the build issue! This unblocks the rest of the rebuilds for LLVM9 for testing now.

Thanks, I updated the package list per rCOMN7649dd796c13 and added the missing ones to the list.

@aleksvor thanks for the catch. It didn't get pulled in when i ran make clone on the repo for some reason. I'll do some digging on why make clone isn't pulling down all the packages.

New rebuild list. Now over 600 packages. https://pastebin.com/raw/WEbQgVjx. Rebased everything against the GNOME update and have had python3.7 and the rebuilds installed on my system for a few days now without any problems noticed, just trying my best to look for any breakages and missing packages currently.

A bug in geos autotools scripts means it can't be switched to python3. Infact, support only explicitly goes as high as python 3.3, as seen here. Their cmake scripts do not support enabling python bindings at all.

Resolved the zita-resampler issue thanks @Staudey for the pointer.

Actually updating glibc to 2.30 locally seems to resolve the segfault. Won't reopen till 100% sure.

Confirmed, but, cannot find a consistent way to make it segfault. Just running the timer and clicking around the app and hoping it segfaults.

You may manually extract the ppd files from their provided .deb and place them in /usr/share/ppd/xerox. That _should_ be that is all required, but you may need some additional utilities from the deb to get it working. Good luck!

Blockers are resolved. Rebasing and rebuilding against updates in unstable and starting more thorough testing.

If you still have the issue of pdf's not rendering after updating feel free to reopen the task.

In T8364#158716, @AI_I_EN wrote:

No, you can just use photos and then try it

Do you have libtiff installed? sudo eopkg it libtiff. That could just be a missing rundep. As for pdftk it is not currently packaged in solus.

Are these required as part of qomui itself or only the WireGuard component of it?

Alright, looks like we need to package geoip, geoip-database and maybe geoip-database-extra from http://www.maxmind.com/app/c

Any other problems, i.e. missing rundeps, please create a new task.

Try installing python-geoip first

Confirmed. Seems pretty annoying

Have a strange issue with gnome-terminal not loading. It times-out and doesn't start.

I think i've found the issue; https://gitlab.freedesktop.org/poppler/poppler/issues/766. We'll have to update poppler to at least version 0.77 to resolve this issue. When poppler is updated all reverse dependencies need to be rebuilt against the new version so it'll take a while, especially as Josh is in the middle of performing a GNOME stack upgrade right now. As an interim solution you could try installing the snap or flatpak version of okular, or using the a different pdf viewer.

Alright, i've updated gdb, can you try to manually install the new gdb from unstable by running;

So, in addition, you seem to be running up against a problem with gdb itself unrelated to okular, unluckily for you, as evidenced by https://bugzilla.redhat.com/show_bug.cgi?id=1560010. I'll have to update gdb first to resolve it, so you'll have to bear with me a couple of days. Apologies for the inconvenience!

If you are unable to provide specific documents that cause the crash please provide a backtrace instead. To do this;

Will need to be rebased against R4672:f70316c55e2d, sorry for being a PITA.