- User Since
- Feb 8 2017, 10:18 PM (244 w, 6 d)
Apr 25 2021
@DataDrake is there any more information on what is the actual issue? I'm tempted to look into that.
Apr 24 2021
See https://dev.getsol.us/D10912, wine 6.7 is released.
Apr 15 2021
Mar 25 2021
You're welcome, glad it helped.
Mar 24 2021
What you could try is forcing the mode for the displays. Or try to generate a proper edid and override that in the kms/kernel.
Oct 23 2020
Fair enough, thank you for the clarification Josh.
Oct 17 2020
Jul 14 2020
Due to a lack of response, I guess this can be closed.
Jun 17 2020
This maybe sounds crazy, but I got those lockups more and more frequently. I realized that my cat chewed some on my display cables. Replacing them seems to have remedied the issue. Not sure how and why linux would lock up due to display cables being eaten, but that actually seems to be the case.
May 17 2020
I did a completely fresh install yesterday (unrelated reason, wanted Budgie again but realized that Gnome still has issues with uinput, so back on Plasma). BIOS is up to date quite a while now (mine does not seem to receive updates anymore). I didn't have the hard freeze last day... I'll wait and try to find some kind of source, such ... daily/some day freezes are hard to get an idea of. So ye, needs more info is probably the right status for this one.
May 15 2020
Sounds a bit like this to me:
https://bugzilla.kernel.org/show_bug.cgi?id=196683 stating it's an issue of the kernel ignoring bios settings and/or crashing ehen the CPU goes on low voltage "standby".
I've the "daily lockup" for quite some time now, didn't give it much traction. I am not using NVidia, and I am on -current.
Should be fixed with todays update. Should not occur after todays update, so the errors shouldn't appear on the next package installs / updates after ckb was updated. Cany any of you confirm it?
May 12 2020
ckb-next devs did make good on their promise.
May 11 2020
Systemd guys say it's a kernel bug - so there we go, kernel bug report for uinput:
ckb-next KitsuWhooa said he'll probably patch the daemon with a workaround "tomorrow". If that happens and the workaround fixes our issue I'll try to patch up ckb-next with the patch and request it for release until we find the real root cause of the issue.
Talked to the ckb-next people, very helpful lot!
Happens at udevadm trigger, not at reloading the rules.
Jan 5 2020
Jul 15 2019
The default, yes, but that would be the case afterwards too.
Jun 24 2019
Sounds reasonable. They seem to be discussing the matter on how releases should be handled in future. There seem to be only a handful of people committing, and as a community driven effort there will be quaters with more/less commits.
Jun 14 2019
Sep 25 2018
For documentation, who knows if G+ will be around longer than solus? ;-)
Sep 24 2018
Aug 24 2018
Nov 22 2017
Thanks @JoshStrobl - because I need multi workspace, that really helps me. Thanks for staying on this and solving it.
Nov 15 2017
Nov 14 2017
I could live with an official VSCode snap. I would prefer it to be native, but if Microsoft is too slow adopting it's the only option which makes sense for Solus. My issue is that I will not install unofficial snaps provided either by Solus or the software vendor. Trust issues to 3rd party.
Oct 14 2017
Adding myself. Said I'll test when it's published, will do so.
Sep 28 2017
It's not crucial to provide the latest software if it:
- does not build properly WITH current software used by dozens of other projects
- is not system critical
- is not in the default set
- has not a really wide adoption (9 subscribers here, 2 of them being triage-team and josh himself).
Sep 21 2017
Interestingly, I just downloaded at full speed... CDN isn't in place yet, is it?
Sep 11 2017
Get it deployed (For realsies!!!!111) for the weekend (not on, not after, FOR)
The issue is that some games seem to rely on hwcaps path x86_64 for their multilib (sub) path, and this patch renders it from x86_64 to haswell / xeon_phi.
Since hwcaps is available and certainly reports something different in an update from 2.25 to 2.26, for me personally that's breaking ABI and shouldn't have been done in the first place.
Sep 4 2017
Maybe I'm blind... I can't see the difference except for maybe some image compression saving the screenshot.
Aug 28 2017
Can you please provide:
DRI_PRIME=1 glxinfo > glxinfo.log
Aug 25 2017
Redistribution is definitely not permitted, especially since ot is a competing product using CIPSofts IP. There have been very clear statements by them a lot of times, and you get banned of the game/forums just for mentioning OT.
Aug 24 2017
No, can check that tomorrow evening, but I do not see that helping this issue.
Aug 23 2017
Its already on the budgie tracker., opened it a while ago.
Aug 22 2017
@JGH1000 there maybe is, and there may be a way to work around the licensing issue as well with the new Snaps support but we'd have to bundle certain applications which require CUDA to be bundled in snaps, with older GCC and the application - those where it makes sense, and probably Blender and others are candidates for that.
I can confirm by now - adding the "nomodeset" option makes the issue go away completely. It seems drivers and KMS are getting in each others way in qemu when "booting too fast".
Or not .. reopening. It works on the first boot actually. It seems it's loading KMS and takes some time on the first boot, on the 2nd it's a lot faster and then I get the yellow screen. Probably a side-effect of booting fast?
Hi @DataDrake ... this issue fixed itself somehow in the latest updates... closing therefore.
Aug 15 2017
Aug 8 2017
Aug 6 2017
@kyrios123 just out of curiosity, how does archlinux manage that if they are always on the latest versions? Do they provide the RC? I can not work on this issue though, no NVidia card anymore..
Aug 5 2017
And it's live. Thanks @Morcas for testing and confirming (and patience), big thanks @kyrios123 for actually doing the work to make it into the distro, it's very welcome (I prefer hunting bugs than dealing with processes).
Aug 2 2017
Narrowed it down to:
I can see my mistake now. I always have steam installed.
Aug 1 2017
To be true, we'd need @Morcas to reproduce this.
Jul 19 2017
Looks very much like:
May 16 2017
I'd actually open a bug on the amdgpu bugtracker for this providing them with the crash while the -dbginfo package is installed. They're the ones who could possibly find the issue.
May 6 2017
I am able to complete with the installation. Having just one issue, which is pretty obvious.
May 2 2017
Can confirm it for my Win7 Enterprise machine at work as well - had the option after upgrade. So both, Win7 and Win10 worked (showing a vista for both for some reason - but that's not an issue as long as it recognizes it and boots correctly).
Apr 30 2017
That's a hard line. My personal thing is .. I think they jumped over the shadow already going from wine stable to wine dev releases (and knowing now that we had build issues I think it wasn't even necessary to switch to development releases at all). Going from development to even staging with unaccepted patches .. well, ye, introduce the patches if there is a solid reason as there is with the -nine patch.
I edited it already :D..
I just reactivated my WoW acc to check it (after the battle.net wine issue was solved thanks to @ikey as well :D).
- do not see graphical glitches
- performance is a lot better on my rx460 compared to native wine. The difference is actually pretty huge.
Worked for me - Windows boot option available after the update.
Just got the update through the repo .. seems to be fixed, even though, I couldn't build :D.
What may help is the config.log in the workdir of solbuild for wine32...
Could you build it that way? For me, the build just now throws an error because it does not ignore the gnutls errors anymore due to the --with-gnutls option. I've played with replacing the %CONFOPTS% yesterday but that didn't seem to fix the issues either (my guess was that the --libdir option was set twice and for some reason isn't properly parsed), but that does not seem to be the case.
Apr 29 2017
During compile time, it actually finds libgnutls for the 64bit build, but not for the 32bit build. Interestingly, they are installed pre-configure, so I do not know why wine-32bit build does not find -lgnutls....
Interesting is the ouput of the 32-bit configure:
checking gnutls/gnutls.h usability... yes checking gnutls/gnutls.h presence... yes checking for gnutls/gnutls.h... yes checking for -lgnutls... not found checking for gnutls_hash... no configure: libgnutls 32-bit development files too old, no bcrypt hash support. configure: WARNING: libgnutls 32-bit development files not found, no schannel support. <...> x86_64-solus-linux-gcc -m32 -c -o schannel_gnutls.o ../../../dlls/secur32/schannel_gnutls.c -I. -I../../../dlls/secur32 -I../../include \ dispatcher.o hmac_md5.o kerberos.o lsa.o negotiate.o ntlm.o schannel.o schannel_gnutls.o \ dispatcher.o hmac_md5.o kerberos.o lsa.o negotiate.o ntlm.o schannel.o schannel_gnutls.o \
I do have libgnutls-32bit installed.
$ eopkg bl wine Name: wine, version: 2.6, release: 15 Package Maintainer: Ikey Doherty <firstname.lastname@example.org> Release Updater: Ikey Doherty <email@example.com> Update Date: 2017-04-26
Apr 24 2017
@Shadow53 certainly not the case.
- I have a clean win10 install here at home, detected as Vista (running clr-boot-manager update manually, not recognized at all after kernel updates)
- I have a clean win7 enterprise install at work, detected as Vista (running clr-boot-manager update manually, not recognized at all after kernel updates).
Apr 20 2017
Reopening. Last update I did run clr-boot-manager update and it found the partition.
Todays kernel update - windows was gone again from the boot entries.
Apr 18 2017
Nope, still no windows option after this update. Had to re-run update-grub again. Unless I need to configure something special for CBM to work, it's still broken.
Apr 6 2017
- It does not fit the 2-distro-policy, Debian/Ubuntu and OpenSUSE are not releasing this in their core repos - or at least not that I could find it. Therefore it wouldn't survive a package request if they go by the policy (and they usually do).
Apr 5 2017
@JoshStrobl it actually fits the two-distro policy (it's called arabic-fonts in suse 42.2 and fronts-arabeyes in debian/ubuntu).
Apr 4 2017
p11-kit yes, but not p11-kit trust (which is in p11-kit/trust directory and needs to be built seperately, it isn't built by default with p11-kit by default as I know).
Ideally, yes. I've looked that up, and Fedora / RHEL seem to have switched to the p11-kit trust module as well with F19 when they introduced shared system certs.
Apr 3 2017
@palto42 didn't have this one on the radar, sorry.
Mar 31 2017
Thanks to the update in the repos, I could do a real world test, and it showed that there's just a one-line issue:
Mar 28 2017
On a 2nd thought, we need a timeout callback because otherwise if the user does not click, we'll run into the issue that we're blocking solus_update.
You'll want to get the MainLoop() into a variable though, and you'll want to quit it to avoid "hanging" in the background ;-). It will block until the Popen is through though (not when SC quits, but when the command was actually fired by Popen).
Actually, there isn't a mainloop, neither Gtk nor GLib.
Still not merged.
Mar 27 2017
@JoshStrobl most releases they do are feature releases, regardless of the number (major/minor/fix releases - they don't seem to care). Depends on how you see it, I do not see it affecting any SolusOS specific software except probably fotoxx and it's geotag support
There was actually a tag 3 days ago having no KDE4 depends: v17.03.80
Hope I got it right this time, patch for update
Interesting, didn't show up in my search. Marking invalid due to the existing report.