Testing PLASMA-SDDM+znver1.iso 2433

(D27) #1

Hi,
Due to my problem with my SSD not being seen by the system, I could not test 2416 version and was waiting for the next compilation. That is done to-day, and I have chosen “znver1 version” 2433, as my equipment is fitted with Ryzen5 processor.
Boot in live from USB drive, and first big surprise, the boot time was a lightning! Not more than a fistful of seconds…
Then, my first look was to see if the new compilation, actually, listed my SSD, and the answer is yes!
Second surprise, the installation on this SSD, directly from the live session, was another lightning; maybe 25 to 30 seconds… I didn’t notice the real time but it was really fast.
Well, reboot… and everything in order, concerning the desktop and all the software installed.
Third surprise, after changing everything (really everything!) in KDE-PLASMA settings, no freeze at all, as Plasma5 had the bad habit to do…
This version is very well born, and I am very glad for all those who worked at it.
I’m just waiting for the implementation of the repositories, as the lack of too many software doesn’t permit to adopt this version as definitive one.
Congrat to all.

1 Like
(Ben Bullard) #2

Waiting for repositories won’t help as they are simply created from Cooker repos. What you need to do is probably enable some that aren’t enabled. By default only main repo is enabled. Instructions for doing this are in the ‘Resources’ forum.

1 Like
(D27) #3

I know cooker repos are the only ones available.
…But, nor with dnfdragora yesterday evening, neither with your explanations or Mandian’s at the moment, I was able to install anything.
Except the initial update (7 files and 2 reinstalled) => no “cache syncronization” or “unknown command” that’s about all I was able to receive.
Yesterday evening with dnfdragora when marking some repos I was able to see some softs I wanted to try, but there is a big mess with versions, libs, dependencies, etc, and when you want to change something the failure of cache actualization doesn’t permit to go on.
I will try later again (rc or release) when managing repos will come back again to a simple operation.
Thanks

(Ben Bullard) #4

Well color me confused! :confused: So you think these problems will fix themselves? :rofl:

The whole purpose of testing is to report software problems exactly like that so they can be fixed during development. Very few people have hardware to test the znver1 ISO’s and repos so if those of you that have the hardware don’t report these problems how will developers know what they need to fix? I can assure you @bero and @abucodonosor and other devs want users to report just such problems as you just mentioned. Please change your mind about this.

How does a user report such software problems? In a bug report. Separate bug report for each problem. For problems like you just brought up you need the Konsole output of the failed installation attempt in a file to attach to the bug report. Please also attach the omv-bug-report.log.xz to bug reports.

(Ben Bullard) #5

This is relevant to the type of problem you reported and worth a read for all users.

(Ben Bullard) closed #6