How could I know in advance about startkde -> startplasma-x11 rename?

wojcieche · 2019-12-09 16:52:48

Hi,

After the last update my KDE did not start. The reason was change of KDE launch command from startkde to startplasma-x11.
To fix it I needed to investigate and figure out on my own that I should edit this command name in .xinitrc file, as described in this thread: https://bbs.archlinux.org/viewtopic.php?id=249974.

My question is: how could I find out in advance to make this change (or any other such significant change), to upgrade system smoothly? I am curious - how have you found out about this command name change?

Going forward I would like to avoid of what happened now - that my system got broken, I was left with command line interface and having no working PC I needed to search on my mobile phone for ways to fix it.
Next time network may break or anything else also crucial, so I would like to prevent it in advance, or at least know in advance how to fix it.

It is impossible to follow changelogs of hundreds of packages. To me the best place would be a warning message during update with pacman or a post in Latest News section on archlinux.org but I do not understand why such key change was not mentioned in any of these two places. Is there any other, more reliable source where such changes are mentioned?

Please help a newbie understand how to keep track of such key changes in Arch. I do not want my system to fail randomly and unexpectedly and hold my breath on reboot after update, I want my system to be solid and reliable at any time.

ewaller · 2019-12-09 17:21:09

I am not using KDE right now, so this advise may or may not have been useful. Generally, there are release notes that are displayed during a system upgrade that should point things like this out when the appropriate package is installed or upgraded. These messages are enshrined in your pacman logs. I would peruse those logs to see if there were any messages advising you of the condition.

Really serious things are also posted to the news page https://www.archlinux.org/news/

ugjka · 2019-12-09 17:53:44

Sometimes you don't get any clues when something changes other than people coming here to whine about their breakage

jasonwryan · 2019-12-09 17:55:26

wojcieche wrote:

that my system got broken, I was left with command line interface

This is an oxymoron.

Trilby · 2019-12-09 17:57:31

wojcieche wrote:

I was left with command line interface and having no working PC

Your system was still working just fine - anything you can do from plasma, you can do on a tty, it will just look different.

wojcieche wrote:

I needed to search on my mobile phone for ways to fix it.

The installation iso has at least one textmode browser, I'd suggest you keep on on your system too. Worst case you'd have curl.

wojcieche wrote:

or at least know in advance how to fix it.

Get at least moderately comfortable managing your system from a tty. This is how you installed it, so you should be able to manage it from there too.

ugjka · 2019-12-09 18:46:26

If we don't define "broken" here, we are discussing apples and oranges.

I would define my system as "broken" when i need the installation medium to fix my system.

Trilby · 2019-12-09 19:10:51

I'd define my system as "broken" if and only if Allan has had access to it. But that's besides the point. Put aside the semantics: the OP felt like they couldn't take productive steps when they were in the tty ... they should be able to take productive steps there.

wojcieche · 2019-12-09 21:56:02

ewaller wrote:

Generally, there are release notes that are displayed during a system upgrade that should point things like this out when the appropriate package is installed or upgraded. These messages are enshrined in your pacman logs. I would peruse those logs to see if there were any messages advising you of the condition.
Really serious things are also posted to the news page https://www.archlinux.org/news/

OK, but I already said that I read in both places and startkde rename was in none of them - neither pacman logs, nor in the Latest News.

ewaller wrote:

I am not using KDE right now, so this advise may or may not have been useful.

Well OK, but I can say the same - I do not have mariadb and libbloom packages on my system yet they were highlighted in the Latest News, which was not useful for me.
KDE Plasma is one of two major desktop environments, so it still seems rather important to me to mention it there. But probably best it would be in pacman log, which apparently KDE team didn't bother to add and it might have been first and foremost their responsibility to highlight this key redesign change to the users.

ugjka wrote:

Sometimes you don't get any clues when something changes other than people coming here to whine about their breakage

Thank you for the reply. I get that such situations sometimes will happen, I just try to understand what is the best practice to be able to effectively avoid them to the extent possible.

wojcieche · 2019-12-09 22:08:15

jasonwryan wrote:

wojcieche wrote:
that my system got broken, I was left with command line interface
This is an oxymoron.

Trilby wrote:

wojcieche wrote:
I needed to search on my mobile phone for ways to fix it.
The installation iso has at least one textmode browser, I'd suggest you keep on on your system too. Worst case you'd have curl.

Nope, it is not an oxymoron. Having no GUI does not allow to browse internet efficiently to look for help. Text browser would be an inferior option of last resort in this case.

Trilby wrote:

wojcieche wrote:
I was left with command line interface and having no working PC
Your system was still working just fine - anything you can do from plasma, you can do on a tty, it will just look different.

Actually system was not working fine - WiFi didn't work as normally it is run in KDE through network manager. In tty I had to fallback to wpa_supplicant + dhcpcd.
But in general I do understand that Arch is a fully functioning system even without desktop/window environment. My only point above was that in this case there was no GUI but in the future it can be even worse, which I would like to avoid to the possible extent.

Trilby wrote:

wojcieche wrote:
or at least know in advance how to fix it.
Get at least moderately comfortable managing your system from a tty. This is how you installed it, so you should be able to manage it from there too.

Yes, I do. I have not said I am not willing to work in tty. As you cited, I only said it is better to know in advance what I should fix in tty, if such maintenance action is necessary.

seth · 2019-12-09 22:28:47

do not have mariadb and libbloom packages on my system yet they were highlighted in the Latest News

Those packages required manual intervention for the update process itself, that's different. The startkde script drop (was a pretty stupid upstream decision to begin with, but…) should have been announced w/ the package release notes, but unfortunately https://www.youtube.com/watch?v=5RyYrs5tu60

Something like

exec $(awk -F= '/^Exec/ { print $2 }' /usr/share/xsessions/plasma.desktop)

might be more robust.

Nope, it is not an oxymoron. Having no GUI does not allow to browse internet efficiently to look for help.

1. Google "where there is a shell, there is a way"…
2.
- https://www.archlinux.org/packages/comm … 64/elinks/
- https://www.archlinux.org/packages/comm … ikicurses/

wojcieche · 2019-12-09 22:46:23

ugjka wrote:

If we don't define "broken" here, we are discussing apples and oranges.
I would define my system as "broken" when i need the installation medium to fix my system.

OK, so my definition of broken is the simplest and most basic it can be: after update something stopped working or works seriously worse (like serious performance degradation).
Another example of a very problematic breakage that I would like to avoid in advance is that my printer stopped printing, with a message: The PPD version (5.3.1) is not compatible with Gutenprint (...)
I learned about this issue only when I needed to print something in a hurry - which is the worst possible timing to discover something stopped working, the worst moment to spend time looking for solutions.

Trilby wrote:

I'd define my system as "broken" if and only if Allan has had access to it. But that's besides the point. Put aside the semantics: the OP felt like they couldn't take productive steps when they were in the tty ... they should be able to take productive steps there.

Thank you for trying to understand me without nitpicking about words and without off-topic remarks. I was hoping to get some concise advice from practitioners, but so far I learned nothing new. Nobody answered the question how to avoid issues in advance. I knew before to read pacman log and Latest News and I said these sources failed to warn me.
However I am asking in general everyone here - everyone in this topic somehow tracks what is changing, so I am asking for your experience - should I understand that you all only read pacman log and News and fix things only when you at some random moment learn they got broken? Is this the only recommended best practice?

Trilby · 2019-12-09 22:53:06

wojcieche wrote:

everyone in this topic somehow tracks what is changing

Not really. Except to the extent that when something "break" I know something changed. I then fix it.

wojcieche wrote:

should I understand that you all only read pacman log and News and fix things only when you at some random moment learn they got broken?

For me yes. Except I don't read the news either unless I have a concern (if something "breaks" I do first check the news, but I don't pre-emptively or proactively check it).

wojcieche wrote:

Is this the only recommended best practice?

I'm not sure if it's the only method. Different strokes for different folks, of course - but for me I value the (very rare) breakage as an opportunity to be pushed a little out of my comfort zone and to learn more.

seth · 2019-12-09 22:55:37

OK, so my definition of broken is the simplest and most basic it can be: after update something stopped working or works seriously worse (like serious performance degradation).

That's called "regression".
You might simply be using the wrong distro. There're no guardrails in arch (or any bleeding edge rolling release distro) and you have to be prepared to deal with situations as you find them.

As for the printer: do you by any chance use a driver from the AUR for it?

Zod · 2019-12-09 22:55:45

You seem to be a good candidate for a point release distro?

I don't see how the rolling release model fits in with your concerns.

I'm not trying to be a shit, it's just an objective observation.

judd1 · 2019-12-09 22:59:10

Theme that goes nowhere ...

ewaller · 2019-12-09 23:00:22

wojcieche wrote:

ewaller wrote:
Generally, there are release notes that are displayed during a system upgrade that should point things like this out when the appropriate package is installed or upgraded. These messages are enshrined in your pacman logs. I would peruse those logs to see if there were any messages advising you of the condition.
Really serious things are also posted to the news page https://www.archlinux.org/news/
OK, but I already said that I read in both places and startkde rename was in none of them - neither pacman logs, nor in the Latest News.

I went back and reread your post, and I was correct. No, you had not stated that you had read the logs. And, as to the warnings during an update, you only asserted that that would be a a good place for them to be -- not that you had seen them.

The answer to your question as to where to look is: look in the news, the logs, and the install warnings. I did not assert that they were actually there in this case. A could not make that assertion as, like I stated, I don't run KDE

judd1 · 2019-12-09 23:07:06

wojcieche wrote:

I do not want my system to fail randomly and unexpectedly and hold my breath on reboot after update, I want my system to be solid and reliable at any time.

That does not exist, sooner or later something breaks.

Trilby · 2019-12-10 00:20:53

Eh ... I'm usually the snarky one around here, but it seems like the OP is getting some unwarranted crap here.

The OP wants to understand how to be better prepared for the changes that may come with updates. The suggestion to consider a point release distro is good, but side-steps what may be at the heart of the question, i.e., assuming one wants to use a rolling release, how can they keep informed and prepared for the changes.

My style is not likely particularly useful to the OP: don't prepare, and just get better at adapting. But I doubt all archers are as masochistic as I am with my OS. So how others prepare and learn is a fair and good question.

judd1 · 2019-12-10 01:49:05

Trilby wrote:

Eh ...but it seems like the OP is getting some unwarranted crap here.

It does not seem ...

Trilby wrote:

But I doubt all archers are as masochistic as I am with my OS.

Obviously not, it is only a way to accept and live with a rolling distro.

Zod · 2019-12-10 02:43:10

As an end user of a rolling release distro I accept the fact that it is impossible to know about and prepare for every change. What seems like a small obscure difference for one person can be a show stopper for the next person.

One thing that works to my advantage is that my daily driver is not a production machine. It's a passion, it's fun, it's art, it's a hobby and it needs to reflect that reality. All these things come together and the result, for me, is an old HP 8760w laptop running Arch Linux (BTW, all the things work out of the box).

Having said that, there is only so much one can do, front page news, forum, mailing lists, but is that enough? It is for me because I don't dread the occasional breakage. That's the thing though, isn't it? To right size the choices one makes, one of the things I love about Linux is the ridiculous and sometimes overwhelming number of ways you can accomplish a goal.

Choices, options...if you choose to run Linux you have them and it's up to each individual user to find what works for them.

jasonwryan · 2019-12-10 02:50:59

If you spend enough time here, you'll learn that updates to the major DEs (gnome, kde and, to a lesser extent, xfce) generally involve some degree of carnage. These systems, by their nature, are very complex and comprised of lots of interdependent moving parts. They are, IMO, better suited to point release distros.

Those of us who prefer lighter weight approaches using loosely coupled tools find rolling releases much less painful. I've used Arch on my work machines for over ten years now and have not lost any time to breakage*.

I also stand by my claim that if you think that a GUI is the definition of a working system, Arch is not a good fit. Not for reasons of breakage, but for the ability to confidently respond to change.

* Some time has been lost to tinkering, granted. Like last week when I migrated my mutt setup from LDAP to CardDav address lookups...

seth · 2019-12-10 07:43:20

1. be prepared for the worst (there's a grml usb key on my keyring because, no, I'm not gonna use curl)
2. have time to lose ("I'm desperately gonna need *this* system in 30 minutes, so I guess it's time for a pacman -Syu" is NOT a sane thought)
3. skim the forum. If there's a systematic issue w/ a new release of <package>, you'll stand a chance to learn ahead
4. If you maintain multiple independent systems, don't update them in parallel (because *if* there're problems, you'll have to deal w/ those in parallel as well, raising the "have time" issue)
5. Be bold. Even the most sophisticated battle plan does not survive the first enemy contact (the elder Moltke) - but you'll have to fight. So you'll eventually rely on your skills to deal w/ the situation as you find it.

Since arch doesn't run integration tests, it's either the above or you've to look for a distro, dedicated to your preferred software stack, that does.
You might still face trouble with such distro. Windows updates are typically a disaster. This is where Jasons lightweight comment comes to play. Complexity is the enemy of reliability. Also the windows update system is garbage.

Alternatively, hire an IT service to maintain your system(s).

Lone_Wolf · 2019-12-10 14:47:04

Some other actions that can help to get a warning before something breaks :

- subscribe to arch-dev-public ML

- subscribe to the [testing] Repo Forum
https://bbs.archlinux.org/viewtopic.php … 4#p1864744 was the first time the startkde breakage was reported on archlinux forums.

Arch Linux

#1 2019-12-09 16:52:48

How could I know in advance about startkde -> startplasma-x11 rename?

#2 2019-12-09 17:21:09

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#3 2019-12-09 17:53:44

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#4 2019-12-09 17:55:26

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#5 2019-12-09 17:57:31

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#6 2019-12-09 18:46:26

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#7 2019-12-09 19:10:51

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#8 2019-12-09 21:56:02

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#9 2019-12-09 22:08:15

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#10 2019-12-09 22:28:47

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#11 2019-12-09 22:46:23

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#12 2019-12-09 22:53:06

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#13 2019-12-09 22:55:37

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#14 2019-12-09 22:55:45

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#15 2019-12-09 22:59:10

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#16 2019-12-09 23:00:22

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#17 2019-12-09 23:07:06

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#18 2019-12-10 00:20:53

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#19 2019-12-10 01:49:05

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#20 2019-12-10 02:43:10

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#21 2019-12-10 02:50:59

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#22 2019-12-10 07:43:20

Re: How could I know in advance about startkde -> startplasma-x11 rename?

#23 2019-12-10 14:47:04

Re: How could I know in advance about startkde -> startplasma-x11 rename?

Board footer