Always read post 2 for potential issues and solutions

I believe one of the Mods [correction: a contributor to the Wiki, in Dec 2023] told me he would be copying/adapting that whole paragraph 1 of the current wiki entry from a previous post of mine.

However, this current hived off thread (I think you missed my gentle humour about having my own thread) started by being a proposal to Phil to ALSO remind readers about post 2, right at the top of the first post of every update announcement thread.

It’s easy not to know about post 2, when post 1 can be very long and the user just wants to get to updating after scrolling through post 1. I would guess that even fewer users will read a Wiki entry than an update announcement before they jump right into updating.

Did you read the link I posted 2 posts up? I have advocated since the very first Manjaro forum (been a member since 2012/2013) that the warning be given at the most logical place - in the graphical updater – so users who rely on the GUI tool (most likely group to face issues, IMO) – spot the warning. I provided the example of Rigo, Sabayon’s graphical updater that had the warning popup, to show that this was possible in real life, and beyond just proof of concept.

Every few years, a hugely problematic update hits, and people post outraged posts complaining about the same old things as in the current plasma 6 update - why didn’t anyone warn me before the update? If the pamac GUI is not cut out for such big updates, why continue to use it? At least have the updater warn me before I start. How would I even know about having to read update thread? etc etc

When Manjaro the company began selling computers with Manjaro preinstalled, I raised this proposal again. How in the world would people who just bought a computer to use, realise the OS on it needs care in updating? Why in the world would they realise they have to check a forum?

THis is at least the 3rd time that I proposed having the warning directly in the updater-GUI.

But that does not mean it’s useless to mention post 2 in every post 1. I think it’s a good reminder, to educate users, since there will be some that read the forum thread. Probably more so than people who conscientiously read the installer or welcome screen.

Wrong premise. You are assuming that Manjaro would be a consumerist platform. It is not, and no Arch-based distribution will ever be, exactly because of the Arch underpinnings.

Manjaro is a distribution for people willing to commit to maintaining their system and reading the documentation — just as is the case with Arch proper. And the same is expected from people buying any of the devices that come preinstalled with Manjaro.

:point_down:

1 Like

OK. I hope they know that! :stuck_out_tongue_winking_eye:

Well, that would be up to the marketing department, and that’s beyond my pay grade… :man_shrugging:

Perhaps it would be even better (if probably still ignored) if the pamac GUI popped up a prominent warning for any significant upgrade, since that’s probably where most people are going to find out about updates.

I have mentioned this before; also in another thread…

Manjaro Hello is a prime candidate to address much of this concern. I doubt there is anyone here who will fail to see the significance of this app that opens by default in both the Manjaro Live Installer and Manjaro first run.

1 Like

It is - but consider this - the majority of the user base very quickly disable the auto start of Manjaro Hello on the their system.

And they are not likely to open it to figure out if they should update or not.

The majority don’t even check the announcement thread before updating.

When anyone buys a system with Linux preinstalled - it is deliberate choice - just as the hardware they buy is a deliberate choice - not likely made on a whim but made from a careful research on hardware, prices, competition etc.

Hardware with Linux preinstalled is rarely bought by a novice computer user but only as either a fully thought through process or simply to try it.

2 Likes

This only equates to ignoring the help given which is synonymous with the result of virtually every other attempt to provide due dilligence.

For the benefit of those who will be interested enough to RTF announcements, notifications or whatever else might be offered, Manjaro Hello is, at least, a good place to start. That said, there is likely a practical limit as to how many accessible locations can be utilised for the purpose, and how many of those might actually be effective.

At the end of the day (and as we’re all aware), there are a certain percentage of users who will disregard any opportunity to learn; and still argue that Manjaro is somehow responsible for their own ineptitude or ignorance…

…and for those people, the only recourse seems to be…

Let the Good God Darwin sort 'em out!

1 Like

16 May 2024: Updated: caught by surprise by the update to Plasma 6 - #77 by nikgnomic

Manjaro forum could have helped a percentage of users by not having a learning delay of 6 hours for Plasma 6 Known Issues & Solutions

Since last year (when some Xfce users were “blinded by the light” of pamac) there is only community support for Xfce-specific issues from Unstable and Testing Branch users

1 Like

Am I to understand that this was not in place until six hours after 24.0 reached GA? That being the case, I was unaware of it, however, I’m forced to agree.

I’d actually like to see an enforced delay - but in the other direction - that is: delay the release until supporting documentation is in place.

That could give time to allow a countdown to release with known issues to the fore of any pre-emptive notifications. Of course the nature of Linux communities is such that this is possibly untenable, without some steering involved.

It seems to me pamac-GUI is the most logical location to place any update warning and request to check forum thread first.

Yes, it requires the Manjaro team to do some re-programming of the pamac code, but that’s why I provided the Rigo example. It would appear the source code is still available.

Interesting. I must have missed this.

I note your point that the forum posts 1 and 2 themselves should have given some warning about Plasma 6 right from the time the updates dropped. Should be easy enough to coordinate.

It was clear from the past few months of Plasma testing that widgets, themes etc might cause issues if not reverted, that even plasma 5 configs might be an issue. That could easily have been placed into post 1 and 2 from the start.

While I would always recommend everyone to read the Stable update threads, you can’t expect the ordinary Stable user to also read the Testing/Unstable threads. They chose to stay on Stable for a reason. Warnings should have been copied over to the Stable thread.

1 Like

Total agree with that point, i was looking a few times in testing branch (which can’t expect from everyone, who isn’t using testing) and i saw at least from my 5 visits that Know Issues in Testing Branch wasn’t in sync with Known Issues in Stable Branch.

1 Like

Well that can happen since users found out that depending on their trust level they can add to that known issues post … so some do. And regardless of the quality of those additions … they rarely follow it up with also applying it to the other thread(s).

1 Like

…or, at least, have all issues accessible (and noticeable) at a central location; this is likely best suited to the Manjaro online presence.

I’m tempted to suggest that the existing notifications source might be leveraged for this purpose, perhaps in a banner-ad-esque approach, such as touted by @Kobold any time he has the opportunity.

As much as I dislike that idea on the desktop, perhaps a rework of the notification app might even be worth consideration.

1 Like

The fact that with the major Python update arriving in the same update as a major KDE update meant I had two things that needed a lot of manual intervention at the same time.

I read about manual rebuilding before doing my update. (On Topic: it was not much to read to know whats going on)
Then I checked before upgrading and thought there would be a lot to do. But after upgrading I checked the rebuild-status again and everything was already done. And everything was running smooth. So I think it was a fine move to do it all at once.
(I didnt have a lot of time and had do wait - when I updated the second batch for stable was included)

1 Like

My understanding is that there’s no need for rebuilding Python packages if they were installed from the standard Manjaro repos. I may be something of an outlier in that I have some installed from AUR, some from source, and quite a few installed through PIP. But then it seems an awful lot of what’s vital for my workflows has to come by those routes…

I have found that with compiz packages (yes, I continue to use compiz with xfce) which include quite a few that are python-based, I only need to do a simple rebuild whenever rebuild-detector informs me it’s necessary. I’ve never had to deal with python sub-directories, whether it’s clearing a folder for an older python version or whatever.

It probably is dependent on the package in question.

Am I to understand that this was not in place until six hours after 24.0 reached GA? That being the case, I was unaware of it

Everyone missed some of the things, but the important things were sorted out by someone
and anyone can read the history and consider how to avoid or mitigate update problems in the future

Wiki edits usually have a related post in the topic. The top dudes for the May massive update are:

As far as I could see at the time, comments prior to wiki edits were reporting a lack of information to read in post 2. But I was on the lookout for non-KDE issues and off-topic stuff to move out of the dogpile

delay the release until supporting documentation is in place.

There was a gitlab page showing the release blockers. Maybe that could include items for documentation and implementation linked up to “known issues” in Testing

Manjaro Team and community did excellent work on the packages, but deployment of the update to stable branch was lacking warnings and information

I posted to Testing branch wiki last year and information was copied across to Stable branch no problem. But this year I had to copy 2 or 3 posts from Testing to Stable. This is not optimal for users if I am not on the forum for a day or 2 to check update announcement

user wiki content seems to be good for quality

No comment about moderators. They should be doing their own introspection


I recall a couple of times since 2016 when PhilM “strongly recommended” all users to log out and update from TTY, but I don’t recall this being needed for only one DE before
This should be considered ahead of time and posted on time to stable branch

.pacnew files should be notified automatically, with specific merge instructions decided for each case if needed

And we should be spamming everywhere with messages to read the update announcement if another massive one is expected

5 Likes

I had a test Garuda VM for over a year at one time and the distro has hooks set up so that after an upgrade (terminal commands of course; pamac is frowned upon there), all the as yet unattended pacnews are listed. You still have to deal with it yourself, but it’s a good reminder (nag) to at least deal with the more pressing ones when you see your pacnew list piling up.

Again, unless this can be incorporated into the pamac GUI, it’s not going to be of help to the users most in need of the reminders, ie those who upgrade with the GUI.

I’m not sure though that specific merge instructions can be given for most pacnews that will apply in general to all users. Except maybe “don’t merge the pacnew for passwd!!”.

Users and groups - ArchWiki (end of section 6)

There are at least 2-3 topics with scripts about pacnews. I use my own simple script, but there is the official pacnew notifier from Stefano Capitani. With hook and gui. So it exists but is a little beta to be included by default i think.
To sum up:if someone wants, he can find a lot of stuff in the forum. But with a little searching.

2 Likes