- User Since
- Oct 14 2017, 8:34 AM (187 w, 14 h)
Apr 27 2020
This time it should be. Sorry for spam, folks
Apr 26 2020
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). How can I fix it?
I have reworked my git trees. This time, it should be better.
Does this fix the problem?
Apr 13 2020
Side question: why is T8611 linked to this diff?
Added python3 as rundep
Apr 12 2020
Thanks for your comment. I've removed that
Apr 9 2020
Fixes release number
Sorry folks, arc created a new differential.
Mar 23 2020
Bump to version 3.5.1
Mar 19 2020
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.
Jan 20 2020
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.
Jan 19 2020
Dec 21 2019
Dec 4 2019
Nov 29 2019
Nov 28 2019
This version needs python-pythondialog to get accepted. See T8512
Thanks. I'll send patches in a few moment.
Nov 27 2019
Oct 22 2019
Oct 16 2019
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?
Oct 4 2019
wayland-protocols has been updated to 1.18 with this week's Sync.
As such, there is no blocker anymore.
Oct 1 2019
Add the conflicting with rust and cargo, changes the symlink created.
Sep 26 2019
Add rust as a conflicting package and add appropriate symlinks.
Sep 22 2019
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).
Sep 21 2019
I'm gonna make a new diff for this update. Sorry for the spamming.
Sep 17 2019
Oops, sorry for that. Should a open a new diff or is there a way to correct this one ?
Sep 13 2019
Aug 3 2019
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 :)
May 28 2019
This task is a duplicate of T565, which has not been accepted.
May 24 2019
May 5 2019
May 2 2019
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.
May 1 2019
Fixes release number.
- Bump to rustup 1.18.1
Apr 22 2019
Ooops sorry guys
Mar 24 2019
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?
Mar 19 2019
No. Gnome stack 3.32 may require some changes in budgie. As such, it will land later in the repository (see The Roadmap)
Mar 16 2019
Remove an useless pipe.
This fixes pspec_x86_64.xml's License section.
Mar 15 2019
Abandoning the revision since this does not resolve the problem.
Fixes wrong repository.
Mar 14 2019
Jan 18 2019
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)
Jan 3 2019
Maybe hardware acceleration can be automatically activated on installation if there is no NVIDIA hardware? (maybe using usysconf)
Dec 27 2018
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
Dec 25 2018
Closing this since it seems to be an upstream issue.
Dec 24 2018
Dec 22 2018
Dec 11 2018
You're right, by default, --new-tab has a strange behaviour.
However, if you run firefox --new-tab about:newtab, it runs as excepted.
Dec 10 2018
Assigning JoshStrobl to investigate and triage. Referencing T7289.
Dec 6 2018
Nov 18 2018
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).
Nov 14 2018
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.
Nov 12 2018
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.
Oct 30 2018
I have no computer with Nvidia graphic card in it, so I can't test for layers.acceleration.force-enabled with Nouveau.
Oct 20 2018
Last time I was so amazed by an update was when Budgie 10 was released. Very nice idea !