Recent stable updates and wxgtk2: what happened?

[hans]

I have created this topic to understand what is happening, why and what to do about it.

Stable update 22-07-18 has a known issue that wxgtk2 has to be removed to allow the update. And that can only happen when programs depending on wxgtk2 are removed first.
These programs may be in the AUR or not (Hugin is not). A solution / work around is not provided, other than to rebuild the AUR program (which will very probably fail) or use an appimage. (Personally I had to remove Sooperloper and Tenacity.)

On Arch News this wxgtk2 issue is mentioned, also without a solution or workaround.

What is happening here? I would expect that before wxgtk2 is removed upstream someone somewhere would investigate the consequences. Now it seems to me that users are left in the dark without any outlook.

Can somebody e.g. from Manjaro Development explain this?

NB Please note that I do not use words like ‘good’ or ‘bad’. I would like to understand what happened.

[linux-aarhus]

@hans

Can somebody … explain this?

These numbers is fictive - they are only used for illustrative purpose.

98% of the packages in the Manjaro repo comes from Arch.
0.5% is an AUR package included in Manjaro - usually because it is used by a maintainer.
1.5% is software developed by Manjaro or build from source by Manjaro e.g. kernel and kernel modules, extra modules like Nvidia driver.

If a package is removed from Arch repo - it us usually demoted to AUR - my guess is that users depending on the package have the opportunity to adopt it and maintain it

When such thing happens - the package cease to exist in Manjaro unstable and subsequently stable branch.

@hans

I would like to understand what happened.

Arch summer cleaning?

[omano]

@hans

What is happening here? I would expect that before wxgtk2 is removed upstream someone somewhere would investigate the consequences. Now it seems to me that users are left in the dark without any outlook.

Package got dropped from repositories. You’re using or have installed packages (not from the repositories) requiring that package. You have issues because of that.

[Aragorn]

@hans

What is happening here? I would expect that before wxgtk2 is removed upstream someone somewhere would investigate the consequences. Now it seems to me that users are left in the dark without any outlook.

Can somebody e.g. from Manjaro Development explain this?

With the disclaimer that I am not a developer or package maintainer — I am but a lowly, lowly cook moderator — the package that replaces wxgtk2 supports all that wxgtk2 supported.

@philm

Packages have been renamed from wxgtk- to wxwidgets-. The GTK2 frontend is no longer provided. If you have wxgtk2 installed, the upgrade will fail with:

error: failed to prepare transaction (could not satisfy dependencies) :: removing wxgtk-common breaks dependency ‘wxgtk-common’ required by wxgtk2

In such case, uninstall wxgtk2 first and then proceed with the upgrade.

So it’s only the replacement of one package by a package with another name, and while it may be necessary to remove wxgtk2 first, it is perfectly possible to do this without removing all that depends on wxgtk2. But for that you have to read the man page for pacman.

[hans]

Thanks for the replies. I use pamac for the stable updates. And not pacman. So now I will have to study pacman to understand what pamac suggests

[Aragorn]

@hans

So now I will have to study pacman to understand what pamac suggests

pamac can do that too, and it also has a man page.

[winnie]

@hans

I would like to understand what happened.

There’s also an alternative series of events that might affect users who do not have any installed packages / PKGBUILDs that require wxgtk2, yet in the past they might have at one point in time.

wxgtk2 remained installed on their system, not being used by anything, yet still causes a conflict when trying to update the system, such as the Stable Updates from July 18.

I explain my experience in the below linked post.

Removing wxgtk-common breaks dependency required by wxgtk2

I believe there’s one extra “detail” in addition to this. Of my three Manjaro installations, two of them have the same packages installed via the AUR. However, only one of them had this issue with wxgtk2. Here’s what I think might have occurred with myself and others: In the past, there might have been an AUR PKGBUILD with wxgtk2 as a dependency. Installing the (mystery) package from the AUR naturally pulled in wxgtk2 from the repositories. Over time, this particular software from the AUR n…

[hans]

I was and am confused by this response in a related thread:

Removing wxgtk-common breaks dependency required by wxgtk2

You need to remove anything that depends on wxgtk2 and also remove wxgtk2 before updating as was already announced. Nothing in the repos depends on wxgtk2 anymore, so whatever depends on it was manually installed by you from the AUR which is your responsibility to manage.

[FrankSBernhardt]

A lot of good information but no actual instructions for newbies (is that politically correct; sorry if it isn’t).

I had the same problem and after reading the man pages I did a “sudo bash” then:

[moria frank]# pacman -R wxgtk2
checking dependencies…

Packages (1) wxgtk2-3.0.5.1-3

Total Removed Size: 15.01 MiB

:: Do you want to remove these packages? [Y/n] y
:: Processing package changes…
(1/1) removing wxgtk2 [######################] 100%
:: Running post-transaction hooks…
(1/1) Arming ConditionNeedsUpdate…

That’s it. The update ran successfully.

If you are worried something will get broken run the Timeshift utility before the uninstall.

Cheers.

[winnie]

UPDATE:

I found the errant package for my situation, which was not an AUR PKGBUILD and not a unique “Manjaro” package: amule

On the computer in which I did a fresh installation of Manjaro in mid 2021, I also installed the package amule, which is from the official Arch Linux repositories.

So even for those who do not use the AUR or custom PKGBUILDs, the Stable Updates from July 18 can still cause this confusing issue. They will not be able to update their system until manually intervening and removing wxgtk2 by hand.

---

Here is the series of events in my situation, in which no part of the AUR was involved:

1. I installed Manjaro in mid 2021. Fresh system.

2. I installed the package amule from the official Arch Linux repository (not from the AUR nor from the Manjaro-specific custom built packages).

3. At the time, amule required wxgtk2 as a dependency.

4. This naturally installs wxgtk2 (since it’s a dependency).

5. After some time, amule (on the official Arch Linux repository) switches the dependency from wxgtk2 to wxgtk3.

• Proof: amule 2.3.3-1 → 2.3.3-2 commit changes to Arch Linux package

6. However, because this is an amule package “update” and not a package “removal”, the unneeded dependency wxgtk2 remains installed on my system.

7. The Manjaro July 18 2022 Stable Updates are rolled out, and since much time has passed, it’s confusing (and difficult to pinpoint the cause) when the system update is aborted because of the conflict caused by the existence of wxgtk2 and the refusal to automatically remove the errant and obsolete package.

---

Re-read my above “series of events” and you’ll see that this could have also happened on vanilla Arch Linux, since no part of the AUR was involved, nor was this due to a “custom” Manjaro package.

Nothing needed to be “rebuilt” nor re-installed. If during the update of amule the package wxgtk2 was automatically removed (since it’s no longer needed as a dependency), there would have been no hiccups later on.

I’m aware that you can configure Pamac (and likewise pacman) to automatically remove unneeded/unshared dependencies upon the removal of a parent package; however, I am not aware of any configuration in which this behavior can be applied to parent package updates.

[anon51566685]

Nice detective work there.

@winnie

this could have also happened on vanilla Arch Linux

Well, yes – that’s why they have an announcement. AUR problems are ignored.

@winnie

caused by the existence of wxgtk2 and the refusal to automatically remove the errant and obsolete package.

If it was a dependency then it should show as an orphan when amule changed ‘depends’, but I guess it was explicitly installed for whatever reason.

Anyhow, if you want to do more investigative work, you can just create dummy PKGBUILDs and play with depends, conflicts, provides, whatever.

Eg.:

# PKGBUILD number 1
pkgname=dummydep
pkgver=1
pkgrel=1
arch=('any')

# PKGBUILD number 2
pkgname=dummy
pkgver=1
pkgrel=1
arch=('any')
depends=('dummydep')

# etc

[winnie]

@anon51566685

If it was a dependency then it should show as an orphan when amule changed ‘depends’, but I guess it was explicitly installed for whatever reason.

It may have in fact become an “orphan” package, but so are make, patch, autoconf, and automake, which I obviously want to keep. It’s for this reason that I won’t just purge orphan packages if there are no issues.

Of course, the situation with wxgtk2 did eventually become an issue, but there’s no way I could have predicted that many months ago.

---

I believe that the logic behind “auto-remove unneeded/unshared dependencies” when uninstalling a package should also apply to package updates as well.

After all, one can mimic the above logic by first removing and then installing a package whenever there is an updated version. It would be tedious and redundant, of course.

---

Here’s how it theoretically would have unfolded in regards to amule:

1. amule 2.3.3-1 is installed. It pulls in wxgtk2 as a dependency

2. I notice that amule 2.3.3-2 is available as an update

3. However, I decide to first uninstall amule, in which wxgtk2 is auto-removed (since it was pulled in as a dependency of amule and no other packages require it)

4. Now I install amule, which happens to be version 2.3.3-2

5. I basically “updated” amule, yet wxgtk2 was auto-removed because of my “intermediary” step of first uninstalling amule

I don’t see why the same above process cannot happen streamlined with package updates, and why it’s only triggered by package removals.

[anon51566685]

@winnie

but so are make, patch, autoconf, and automake, which I obviously want to keep

These are all part of base-devel group so I don’t see a point having them installed as dependencies. If you ever want to change that just reinstall them: pacman -S base-devel --asexplicit

@winnie

I don’t see why the same above process cannot happen streamlined with package updates, and why it’s only triggered by package removals.

Probably because Arch is KISS. Also, I guess, you could argue then, why even have any orphans at all, pacman should take care of everything.

The bottom line is: wxgtk2 needs wxgtk-common, which was replaced (+conflicts) by wxwidgets-common. And it (wxgtk-common) couldn’t be removed because other packages (wxgtk2) still needs it.
And you can’t just automatically remove everything that still depends on wxgtk-common (that would be like doing pacman -Rsc).

The bottom bottom line: They wanted to remove wxgtk2. If they wanted to keep it, they could just rename it, same as wxwidgets-gtk3, and change depends from wxgtk-common to wxwidgets-common.

[Tobias]

The issue still is that temporary removing wxgtk2 with “pacman -R wxgtk2” doesn’t cure the matter, since wxgtk2 cannot be installed anymore after the Jul 18th update is applied. So your apps that use wxgtk2 and had to be deinstalled, too, are no longer re-installable afterwards. For me these apps are mission critical and thus I cannot apply the update. Would be great if someone knows a work around of some sort.

BTW: In the update there is no such package as `wxwidgets-common listed. So it cannot be excluded, but it seems to come as some other dependency.

[anon51566685]

@Tobias

The issue still is that temporary removing wxgtk2

It’s removed permanently. Just like an old kernel or python2 or whatever.

@Tobias

For me these apps are mission critical and thus I cannot apply the update. Would be great if someone knows a work around of some sort.

Find a flatpak/snap/appimage/container of your apps. Or find an alternative way; there is wxgtk2 in AUR for example, that installs in /opt. Find a way to compile your apps against that.

Other than that, there is nothing anyone can do.

[hans]

For example the AUR sooperlooper package does not compile anymore because there is still a dependency on wxgtk2. The maintainer of the aur sooperlooper-git made it compile with wxgtk3. There are a lot of warnings, but it runs.

[Tobias]

I understand that it is needed to remove old stuff that conflicts or poses a security threat, but if there is no conflict, and size certainly isn’t an issue also, where is the point here? Just for sake for new, render elder apps unusable?

Snap - thanks, but “no thank you” for any who is security savy.

If your truecrypt containers do not work with a distribution anymore, it is not just a little replaceable something, but a crucial matter - at least for me. The veracrypt approach won’t help, since it is not proven to be free of backdoors and brute password attacks tools exists.

[Tobias]

This is great: If the maintainer for AUR truecrypt 7.1a before the mystery patch could likewise help, I would be very happy…

[moson]

@Tobias

If the maintainer for AUR truecrypt

Atm, that package does not even have a maintainer

[winnie]

@Tobias

This is great: If the maintainer for AUR truecrypt 7.1a before the mystery patch could likewise help, I would be very happy…

@Tobias

If your truecrypt containers do not work with a distribution anymore, it is not just a little replaceable something, but a crucial matter - at least for me. The veracrypt approach won’t help, since it is not proven to be free of backdoors and brute password attacks tools exists.

I’m trying hard to bite my tongue…

Truecrypt is dead!

The response to the audit reveals that it’s not as “scary” as the report makes it sound (from a “headlines” perspective.) VeraCrypt has active development. TrueCrypt does not. Some of report is subjective (an opinion about how “clean” the code is, which will improve with time anyways.) Any concerns with VeraCrypt are even worse for TrueCrypt (which is abandoned). RIPEMD is only used for legacy (MBR) systems. SHA256…

“Any concerns with VeraCrypt are even worse for TrueCrypt (which is abandoned).”

It’s been abandoned for over eight years.

What is with this loyalty to abandoned software which had its own security concerns, of which open-source developers addressed these very issues when they forked it into VeraCrypt?

---

You love TrueCrypt that much? Why not visit their official upstream website?

---

Top of their website

---

Download section of their website

---