Another possible workaround it to create a symbolic link to one restore and place it ~/.local/bin/, and then rename it to tar-restore, or dump-restore, depending on which is more practical.
As the local reference will usually take precedence, this could be an alternative to the upgrade blacklist. Cheers.
I’m making the assumption that any change to tar for now is minor, so I can safely carry on using the previous version, so I’m happy at present to blacklist it. Especially as dump/restore are an important part of my data security routine.
I’ve joined the bug-tar mailing list and reported this problem to them. With luck, they’ll decide that it’s not a good idea to reuse the name of a long-standing and well-used program.
This was my first October update (so 4, 9 and 13 October at the same time).
During update the system hangs for a long time and was unresponsive. Eventually I had to reboot with the Reisub command. (my feeling says it was a gnome-shell issue and not directly related to the update process)
The update did not complete, but a btrfs-snapshot was made right before the update process. At reboot I selected the most recent snapshot and booted. Then again I did the upgrade process and succeeded.
But now when I reboot the system, the normal boot does not work. No Linux 6.1 image is found. I have to select the recent snapshot in grub-menu to boot. How can i fix that?
Like some people here, I am having problems with KDE after the update.
To summarize: my battery and brightness sliders disappeared. Then I started having problems with KDE crashing (and loosing my work) so I rolled back a BTRFS snapshot to before the update.
More information on my reddit post (I don’t have time to post everything twice, manjaro forum does not let me post the link, so the post is on the manjaro subreddit with title " Broken Battery and Brightness widget after updating")
pamac… - unable to satisfy dependency 'libdav1d.so=7-64' required by ffmpeg
pacman…
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...
:: Replace plasma-framework with extra/plasma-framework5? [Y/n]
resolving dependencies...
warning: cannot resolve "libdav1d.so=7-64", a dependency of "ffmpeg"
warning: cannot resolve "libdav1d.so=7-64", a dependency of "ffmpeg"
warning: cannot resolve "libdav1d.so=7-64", a dependency of "ffmpeg"
warning: cannot resolve "libdav1d.so=7-64", a dependency of "ffmpeg"
warning: cannot resolve "libdav1d.so=7-64", a dependency of "ffmpeg"
warning: cannot resolve "libdav1d.so=7-64", a dependency of "ffmpeg"
warning: cannot resolve "libdav1d.so=7-64", a dependency of "ffmpeg"
:: The following package cannot be upgraded due to unresolvable dependencies:
ffmpeg
Same libdav1d.so issue here. I’ve switched to Kubuntu 22.04 as my main boot a little while ago because I started using Davinci Resolve and audio didn’t work here and I couldn’t fix it after 5 hours.
Was hoping to come back to manjaro as my main after seeing pipewire in the updates, but nope. I love(d) a lot about Manjaro, but this update has reminded me why I hardly boot to it anymore; both the other times I boot to it since maining Kubuntu 22.04 I had issues to fix, and this time I have an issue again and I can’t even figure out how to fix it.
Probably going to keep manjaro around, but kubuntu 22.04 reminded me that nothing manjaro offers come close to outweighing the saved time, if used as a main system for doing actual work instead of tinkering and learning stuff.
This, in itself, is one of the cornerstones of using Linux, no matter what distribution you might consider easier. Every system has its own share of bugs, inconsistencies, and annoyances; frequently attributable to human error or the introduction of foreign software.
DaVinci Resolve, being that it comes from the AUR, is unsupported on Manjaro. The 5 hours of troubleshooting is irrelevant, in my opinion, as is any inference that blame should remain with Manjaro, which is a rolling distribution; a moving target, if you will.
That said, it’s often likely help will be given by forum members, regardless, whether it may take 5 hours (or 5 days) to isolate a problem; dependent on how effectively one provides useful information, naturally.
Wasted time is a luxury not many of us can afford, but is it truly wasted if something is learned through the experience? I think not.
Incidentally, I used Kubuntu once and found it too curated for my liking. Taste is a curious thing, though. Good luck with whichever Linux you choose; and be excellent.
On this system (KDE stable) everything is current, and there is no conflict indicated. I have only recently reinstalled Kodi, which may have upgraded the libdav1d.so version in the process. This might also be true of the other packages mentioned, if any of them have a freshly updated version available.
Updating or reinstalling any of these might resolve the inconvenience of dav1d being downgraded.
Incidentally, there is some active discussion in [Testing Update 2023-10-11] as I write; as well as (scroll up dude/dudette) in the current thread.
An update on the strange conflict between tar-1.35-2 and restore from the “dump” package. Evidently there’s been a “restore” script in the tar bundle for a long time (since 2004), but it appears that it’s only been packaged with Manjaro’s tar bundle from the latest version. It must be that other distros haven’t been including it, as I’ve used several since 2004 without finding this conflict before.
The easiest remedy (only from our perspective) would be for the devs of either package to rename it. From their perspective, I imagine it’s a little more complicated.
Indeed. I suspect this is why distros seem not to have hitherto included the script in their bundles. I’ve just had a look at the Debian and Ubuntu tar packages (admittedly not a great sample as one is based on the other) and the restore script is also omitted from them.
A bit more digging reveals that the dump package no longer exists in the repos. So clearly if it isn’t there it won’t be expected to conflict with files in the tar package.
I think moving my dump and restore files to /usr/local/bin is looking like the way ahead. Or perhaps I need to find time to investigate more modern backup methods (a shame to have to change what I’ve been doing for 25 years, but such is life…)