Always read post 2 for potential issues and solutions

Feedback Forum
41

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
42

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
43

…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
44

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
45

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…

46

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.

47

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
48

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)

49

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