This time it should be. Sorry for spam, folks

Sorry, I wasn't aware of this new commit. Is it correct now?

Pardon my ignorance, but it seems to be good on my side ([see git log --graph output](https://pastebin.com/UCX2WaRH)). How can I fix it?

I have reworked my git trees. This time, it should be better.

Does this fix the problem?

Side question: why is T8611 linked to this diff?

Added python3 as rundep

Thanks for your comment. I've removed that

Fixes release number

Sorry folks, arc created a new differential.

Bump to version 3.5.1

Maintainer of rustup on Solus here
Splitting the rust ecosystem is not a good choice, I agree with you, but rustc, cargo and rustup are different programs, which follow different development cycles. As such, distributing these three programs in one single package would be rather impossible to maintain.
Additionally, this 'big-rust' package would depend on itself since rustup depends on cargo, and so on, which adds even more difficulty.

Changing brightness works as usual if done in tty, using light. As such, I think the problem comes from the X stack or the gnome/budgie stack.

In D7737#124183, @JoshStrobl wrote:

And what is this for? Tasks should be referenced.

This version needs python-pythondialog to get accepted. See T8512

Thanks. I'll send patches in a few moment.

Thanks for your comments. It is fixed now

rustup 1.20.1 was released one day after 1.20.0. Therefore, I copy-pasted the changelog for these two versions. Is this correct?

wayland-protocols has been updated to 1.18 with this week's Sync.
As such, there is no blocker anymore.

Add the conflicting with rust and cargo, changes the symlink created.

Add rust as a conflicting package and add appropriate symlinks.

Hello,
You're right about the changelog, it is fixed now.
Thank you for your remark about the changelog link. I will apply this rule for next releases (where changelog is too long and so on).

I'm gonna make a new diff for this update. Sorry for the spamming.

Hello,
Oops, sorry for that. Should a open a new diff or is there a way to correct this one ?

Hello, I'm the maintainer of rustup in Solus.
I have to admit that I am quite unexperienced with Solus packaging. However, I am willing to learn :)

This task is a duplicate of T565, which has not been accepted.

Abandoning the issue since I haven't found any way to fix it under Solus and haven't enough skills to fix Firefox's source code.

Fixes release number.

• Bump to rustup 1.18.1

Ooops sorry guys

Thank you for your answer.
As far as I know, it is not urgent to upgrade.
I just wanted some feedback because I was wandering why it wasn't accepted.

Any thoughts about this diff?

No. Gnome stack 3.32 may require some changes in budgie. As such, it will land later in the repository (see The Roadmap)

Remove an useless pipe.
This fixes pspec_x86_64.xml's License section.

Abandoning the revision since this does not resolve the problem.

Fixes wrong repository.

Ow sorry, I just wanted to help you :(
So I confirm that a rebuild for rustup should be triggered each time rust is updated

Sorry, I will try to provide the patches the way you want them tomorrow.
(I don't know what happened in my head, but I was thinking about rust 1.32)

In D5083#81262, @Girtablulu wrote:

@josephscade Do I need to do a safety rebuild against this rust + cargo update of your packaged rustup?

Maybe hardware acceleration can be automatically activated on installation if there is no NVIDIA hardware? (maybe using usysconf)

Fix license

Fixed binary file permissions. Thanks @Girtablulu

The script now has a normal behavior. Thank you @livingsilver94

You are right, this is not the cleanest way.
I'm working on it (compiling rustup and then moving it to the appropriate location)

Merged build step and install step
For cargo, it's the same.

Removed useless dependencies

Fixed component. Thanks @DataDrake

Closing this since it seems to be an upstream issue.

You're right, by default, --new-tab has a strange behaviour.
However, if you run firefox --new-tab about:newtab, it runs as excepted.

Assigning JoshStrobl to investigate and triage. Referencing T7289.

Resolved by D4374.

So we now know that enabling layers.acceleration.force-enabled is no longer an issue on Nvidia hardware using both linux-current and linux-lts.
So can we enable it by default?
It seems it has already been changed with recent update to firefox 63.0.3 (see this Differential Revision).

@bwat47,
You're right: as pointed before, gfx.xrender.enabled has nothing to do with scrolling glitches.
I was quoting this answer because @Girtablulu said Firefox runs well with layers.acceleration.force-enabled on Nvidia hardware and Linux LTS, not because of the xrender part.

Hello,
@Girtablulu said in T7189 that it is ok to enable layers.acceleration.force-enabled and gfx.xrender.enabled using Nvidia hardware on LTS kernel.

Thank you for your comment, I'll report it in T7127.

Your issue seems to be related to T7127. Devs said they will enable it if someone tests layers.acceleration.force-enabled using linux-lts with an Nvidia graphic card. Maybe you can check it yourself. It would resolve this task and T7127.

Hello,
I have no computer with Nvidia graphic card in it, so I can't test for layers.acceleration.force-enabled with Nouveau.

Last time I was so amazed by an update was when Budgie 10 was released. Very nice idea !