Hi there,

You're welcome, glad it helped.

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.

Hi there,

Fair enough, thank you for the clarification Josh.

Due to a lack of response, I guess this can be closed.

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.

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.

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?

ckb-next devs did make good on their promise.

Systemd guys say it's a kernel bug - so there we go, kernel bug report for uinput:
https://bugzilla.kernel.org/show_bug.cgi?id=207695

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.

The default, yes, but that would be the case afterwards too.

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.

For documentation, who knows if G+ will be around longer than solus? ;-)

Thanks @JoshStrobl - because I need multi workspace, that really helps me. Thanks for staying on this and solving it.

In T4250#89891, @JoshStrobl wrote:

My issue is that I will not install unofficial snaps provided either by Solus or the software vendor.

Surely if it's provided by the vendor, it's official. Not sure I understand your logic here.

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.

Adding myself. Said I'll test when it's published, will do so.

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).

Interestingly, I just downloaded at full speed... CDN isn't in place yet, is it?

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.

In T4473#79026, @kyrios123 wrote:

In T4473#79020, @STiAT wrote:

Maybe I'm blind... I can't see the difference except for maybe some image compression saving the screenshot.

There is a white background on the first image... maybe you'll see it if you change the contrast/luminosity of your screen ?

Maybe I'm blind... I can't see the difference except for maybe some image compression saving the screenshot.

Can you please provide:
DRI_PRIME=1 glxinfo > glxinfo.log

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.

No, can check that tomorrow evening, but I do not see that helping this issue.

Its already on the budgie tracker., opened it a while ago.

@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.

In T4192#75890, @mrnhmath wrote:

Happens with Windows 7 too.

@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..

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).

Narrowed it down to:
libp11-kit-32bit

I can see my mistake now. I always have steam installed.

In T3874#74064, @kyrios123 wrote:

@STiAT : Just for info I updated D346 yesterday because I noticed that the default certificate trust store path was wrong.
After fixing this, I was able to stream dailymotion videos on VLC which wasn't working before.
I did also give a try to Blizzard App/wine 2.13 (following the notes provided on winehq - install corefonts and vsc2015 from winetricks and setting windows to XP) but still I didn't succeed to get online.

To be true, we'd need @Morcas to reproduce this.

Looks very much like:
https://bugs.archlinux.org/task/54136

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.

I am able to complete with the installation. Having just one issue, which is pretty obvious.

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).

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.

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.

@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).

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.

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.

4. 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).

@JoshStrobl it actually fits the two-distro policy (it's called arabic-fonts in suse 42.2 and fronts-arabeyes in debian/ubuntu).

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.

@palto42 didn't have this one on the radar, sorry.

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:

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.

https://github.com/wine-compholio/wine-staging/pull/333
Still not merged.

@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.

I see the license as an issue for inclusion in primary software repositories, and would require to go 3rd party.

Seems to be a funny dependency issue.

Weired. I reinstalled in a vbox now (clean) + setup solbuild again + updated. No issue, isl gets installed and is installed.