Add openjfx as a rundep

@baimafeima Looks like everything required is already in the repo. Will take a look at it

I think this issue can be closed now. At least this did not happen again

Thank you very much! That resolved it. I already ran eopkg up before but looks like usysconf run -f fixed it

Anything I could try to resolve this? This is is a bit of a blocker for me

@DataDrake As far as I understand it the 2-Distro rule only is important when it does not pass the other rules. But in this case all other criterias are fulfilled

• regular releases
• adds value
• redistributable
• not a server component
• very likely not increasing the stack complexity

Move issue reference to commit message instead title

@kyrios123 Thanks for the clarification. Looks like I've build and installed python-fasteners locally myself to fix this. And then the new package you have added wasn't installed. Sorry for the confusion

@kyrios123 It looks like duplicity is still missing the python-monotonic dependency? Duplicity was still crashing for me. Installing python-monotonic solved it

@kedde I was able to compile at least coreclr. But it can't be compiled with Clang 5 anymore https://github.com/dotnet/coreclr/issues/14757 So this needs to be fixed first in coreclr

@whatever I already have the package ready. Only needs to be accepted

@JoshStrobl Any chance that you had the time to have a closer look at this yet?

Added dependency for D442

So how should i test this? Wait til the fix in systemd hits the stable repo install libinput 1.6 again and then update to 1.7.3? Or simply wait for another libinput update?

That was a fast fix :)

Thank you! Rebooted multiple times after the update but that did not solved it

Updating to 1.7.3 did not resolve it but running sudo udevadm hwdb --update fixed it. Thanks @sunnyflunk and @joebonrichie! A post install mechanism is currently difficult with YPKG i think or any other solution to resolve this automatically?

Added summary and test plan

I did not experience this anymore for a few weeks. I guess this ticket can be closed and be reopened in case it should happen again.

not sure why arc diff created a new diff after the change, but this is the task to go https://dev.solus-project.com/D77

@daveg208 Does this issue still exist? Some fixes for networkmanager-pptp landed recently which at least fixed it for me

issue can be closed now. the last networkmanager-pptp update solved this
https://git.solus-project.com/packages/networkmanager-pptp/commit/?id=108129cfe45b542f86ada411ddd1e93036f24c5e

I get the same error, but installing ppp did not help

Can confirm that this still happens. Checked it on multiple machines

Currently there are two issues with packaging CUDA

• It depends on old library versions of for example libavformat.so. Maybe it will work with symlinks to the new library versions available in Solus, but there is no guarantee for that
• CUDA does not support GCC6 yet. Which might be possible to fix

In T2407#48946, @hjajet wrote:

probably all libphobos.so* files should land in dmd-phobos

Is there any libphobos.so* which is not in dmd-phobos?
But pattern should not require .so.0.*, I will update the patch.

libphobos2.so is still in dmd

i guess dmd should have a rundep for dmd-phobos

I am not sure, it is not necessary to compile anything, it seems to be needed only at runtime.

it looks like dmd is by default linking statically against libphobos.a. so it will not be required as a dep even at runtime http://www.digitalmars.com/d/archives/digitalmars/D/Phobos_still_being_statically_linked_in_273501.html

@hjajet I looked at his because i also ran into the soname version issue and your patch did solve the issue for me. I noticed a few things which could be improved

• probably all libphobos.so* files should land in dmd-phobos
• i guess dmd should have a rundep for dmd-phobos
• export CXX_KIND="g++" is not required anymore. this forces the makefile to use -std=gnu++98 which was necessary for older versions of dmd but has been resolved

Just tested it and unfortunately it still has the same issue for me

Switched back to gradle.org

In the past there were some issues with the GitHub releases and i had to use https://services.gradle.org/distributions But these issues seem to have been resolved with the newer releases on GitHub. That's why i switched back. But i can change it of course back to https://services.gradle.org/distributions

Awesome work! Thanks a lot

Sure. Will look into updating it. But first they need to provide release tarballs of the latest OpenFX plugins releases with submodules included

Right. To many subtasks ;)

Sorry. Here is the updated patch. Also realized i could simplify the prefix install path

Great! Thanks a lot

Added missing abi report

CMake was not necessary at all. Don't know whether it's the best solution with prefix now, but found no better solution yet. Also the install part is a lot cleaner now

Thanks!

Just had another thunderbird segfault and this time got some traceback

Luckily this one was easy to resolve :)
First it needs to land in the repo. Once it's available in the stable repo you will receive it as an update

The two patches above should fix this. Somehow i've missed this, sorry

@mariosant I will take a look this

Thats weird. I've used solbuild and no ABI report was generated

Sure

------------------------------------------------------------
Gradle 3.3
------------------------------------------------------------

Now can be build with solbuild