- User Since
- Sep 25 2018, 1:33 PM (10 w, 5 d)
Mon, Dec 3
Removed gdk-pixbuf builddep since it's being pulled in as a dependency
Per request of @DataDrake, here's the output of ldd /usr/bin/vmtoolsd:
linux-vdso.so.1 (0x00007ffd05dc1000) libvmtools.so.0 => /usr/lib/libvmtools.so.0 (0x00007fae87e75000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fae87e54000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007fae87e4e000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007fae87dfa000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007fae87ce0000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fae87af9000) libdnet.so.1 => /usr/lib/libdnet.so.1 (0x00007fae878e5000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fae878e0000) librt.so.1 => /usr/lib/librt.so.1 (0x00007fae878d6000) libicui18n.so.63 => /usr/lib/libicui18n.so.63 (0x00007fae875fb000) libicuuc.so.63 => /usr/lib/libicuuc.so.63 (0x00007fae87428000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fae873b4000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fae8715b000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007fae87f2b000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fae87140000) libffi.so.6 => /usr/lib/libffi.so.6 (0x00007fae87136000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007fae870be000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fae86f28000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fae86d86000) libicudata.so.63 => /usr/lib/libicudata.so.63 (0x00007fae85398000)
I grabbed the journal for doing the steps @belzael mentioned.
Sun, Dec 2
Mon, Nov 12
Sat, Nov 10
Nov 7 2018
That's just for the beta driver though, not for the main driver. The fix would be the same but the patch is just applied to beta.
Is there a fix now? Also, bump in case it was forgotten.
Oct 30 2018
It stops working after resizing the window a few times though.
@JoshStrobl This is true, but OP asked for it to be integrated by default, which would make sense, but maybe not for Budgie 10 since I think Budgie 11 would need a new control center anyways.
Link to the current repo: https://gitlab.gnome.org/GNOME/librsvg
Lastest release: https://gitlab.gnome.org/GNOME/librsvg/tags/2.44.8
Oct 29 2018
That's a good point but I don't think it makes sense to split packages which are, and will, only be needed by one single application.
If it's being used by multiple other packages, sure, it makes sense. Otherwise I don't really see a reason to.
Go to gnome-control-center to the keyboard section. Now scroll all the way down and hit the plus button. You can put any name in "Open the default terminal", set the command to x-terminal-emulator and set your shortcut.
I can't put it the change into the defaults but at least I can tell you how to do it on your machine.
The maintainer has tagged releases and the setup.sh only extracts the files to the correct place, creates a launcher, downloads some dependencies and extract them too. So my suggestion would be to check if those dependencies could be packaged and then doing the steps in the script via packaging. It would be an easy task to just prep a launcher and the folder structure to package it, as far as i know it's normal procedure to do it this way. From my POV, the dependencies being downloaded in the script are the only problem here.
You can see the scrolling lag horribly and the more programs you open, the slower it gets. I had Ubuntu Budgie running as a comparison and it was a good bit faster. And for open-vm-tools: they don't seem to be active at all. You try resizing the screen - nothing. Shared clipboard? Nope. And so on.
I think i'd just build everything unless there's other packaging using only some parts of it. Otherwise I really don't see a reason to split it up.
@kyrios123 I'd say the performance of VBox guests should be improved first, it's slow as hell. Also, adding to your opinion, open-vm-tools should be included too after fixing T6966: open-vm-tools don't work
Works for me too.
Look like that's a good fix or are there any problems with it?
Oct 28 2018
@aalhitennf Keep in mind that NVME SSDs boot way faster, which might contribute to the problem.
@sunnyflunk that didn't work. See the logs here
@sunnyflunk Here are your files for 390
The 390 output will follow in 30mins - an hour
And you would be correct, it happened exactly as you said.
I have a Intel Core i7 4770 and Solus is booting off a Samsung 950 Pro 512GB NVME SSD but I also have a second SATA SSD plugged in which is being mounted via gvfs at boot.
Here you go:
It worked for me when i booted the pc last time. Is there any way to get more information to be certain about what's going on?
I tried to reboot several times and it seems to be completely random.
This seems like it's happening due to a race condition issue as dicussed with @sunnyflunk on IRC.
It seems to happen randomly when rebooting. Sometimes it loads the NVIDIA driver, sometimes it loads llvmpipe.
Oct 26 2018
$ linux-driver-management status ╒ Hardware Platform ╞ Platform Vendor : Gigabyte Technology Co., Ltd. ╘ Platform Model : Z97-HD3
Sep 28 2018
Still doesn't work :/
How can I give you more info?
Hey Josh, Thanks so much for looking into my issue. sunnyflunk did some research when I first encountered the problem and he said it has nothing to do with the kernel. He went to bed after that so he didn't look into this any further.
Sep 26 2018
Can you update the package request as explained here: Requesting a Package