Recent stable updates and wxgtk2: what happened?

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 :star_struck:

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

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. :point_down:

1 Like

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

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-

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.




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. :white_check_mark: I installed Manjaro in mid 2021. Fresh system.

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

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

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

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

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

  2. :no_entry_sign: 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.

1 Like

Nice detective work there. :slight_smile:

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

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. :smiley:


# PKGBUILD number 1

# PKGBUILD number 2

# etc
1 Like

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. :person_shrugging:

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. :person_shrugging:

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

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.

1 Like

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.

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

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.

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. :smiling_face_with_three_hearts:

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.

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

Atm, that package does not even have a maintainer :wink:

1 Like

I’m trying hard to bite my tongue…

“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

This turn of the discussion is really what I wanted. Evangilism for a different opinion, but not even a glimpse, no word towards a constructive, and knowledgeable hint that will lead to a solution of the funadmental issue.

In the meantime, I got further with the hint here:

patryk commented on 2022-07-21 13:22 (UTC). The solution for that package is simple. Please prepare wxgtk2-3.0.5 package based on AUR (en) - wxgtk-3.1.5. Works for me. Version 3.0.5 is still supported.

compiled these and also compiled truecrypt, which failes due to CPP 17++ “byte” data type usage in Crypto.h as described here: Std::byte - Crypto++ Wiki

Also a wrong encoding of the line end character (mix between windows CR+LF) and UNIX CR only in /src/truecrypt-7.1a-source/Crypto/Aes_hw_cpu.asm made things worse. I gave up when the alteration lead to a failure in the CRC check of the bz2 source therefor and I do not have the private key to redo the packaging.

To the comment on Veracrypt: You certainly can GUARANTEE the security of said product, right? Or might it rather be like this:

Use something which still works
perhaps another distribution
to access and migrate your data
to something that is supported

as this kind of problem
will only get worse with time.

It’s just a fact.

1 Like

I don’t understand what you’re getting at? You can keep on this uphill trek to hold onto TrueCrypt as long as possible if you want. Like @Nachlese said, it will only get worse with time.

But to stand on this ground of “TrueCrypt is more secure than VeraCrypt” doesn’t make any sense. VeraCrypt was forked from TrueCrypt, of which TrueCrypt’s own website (ironically unsecure in HTTP, not HTTPS) and former developers warn everyone in big bold red letters: “Using TrueCrypt is NOT secure”. The software was abandoned over eight years ago.

Don’t listen to me. Listen to them. They are shouting that it is not secure. They are telling people to move their data away from TrueCrypt.

Any argument or snide remark you make against VeraCrypt can be made towards TrueCrypt with greater validity.

TrueCrypt is abandoned. Their own website from over eight years ago tells people “do NOT use this software!” Their own website tells people to MIGRATE their data to a NEW format/container.

You don’t have to, but you’re on your own, as this issue with wxgtk2 is only the beginning of future problems if you stick to a defunct software application.


It might be hard for many to accept the fact that in the light of repression, communication is usually subtle, not forward and obivious. I might be even contradictory. It serves a purpose. Think: old may not neccesarily be bad and new not automatically good. The matter needs to prove itself. Read on: TrueCrypt Encryption Overview - |grepLinux and think: