Upstream has a new 3.0 version in development, which includes GTK+ 3.0 support. Please consider packaging it in experimental.
Hello, I'm Gary Kramlich the lead developer of Pidgin. While 3.0 does work, I think putting it in experimental right now is a bit premature. It's been in development for the better part of a decade (if it hasn't already been a decade). There is a lot of stuff that's in bad shape and is not compatible with Pidgin 2 in any way shape or form (minus the config directory). That said it requires a currently unpackage library called gplugin (written by me) that does have packaging written but is not in any distributions at this time. It does however follow a fairly recent version of the Debian standards. I am working on getting all of this stuff into so packagecloud.io repositories for people to try, but right now having more people dealing with dependency changes and stuff right now doesn't seem like a good use of anyone's time.
Hello, I'm Gary Kramlich the lead developer of Pidgin. While 3.0 does work, I think putting it in experimental right now is a bit premature. It's been in development for the better part of a decade (if it hasn't already been a decade). There is a lot of stuff that's in bad shape and is not compatible with Pidgin 2 in any way shape or form (minus the config directory). That said it requires a currently unpackage library called gplugin (written by me) that does have packaging written but is not in any distributions at this time. It does however follow a fairly recent version of the Debian standards. I am working on getting all of this stuff into so packagecloud.io repositories for people to try, but right now having more people dealing with dependency changes and stuff right now doesn't seem like a good use of anyone's time.
I appreciate the feedback. If you don't think Pidgin 3.0 is suitable even for experimental at this time, and you don't want anyone other than its developers testing it yet, then it probably isn't a good idea to package it yet. My goal was purely to seek a GTK+3 version of Pidgin, and some searching turned up the Pidgin 3.0 branch.
I appreciate the feedback. If you don't think Pidgin 3.0 is suitable even for experimental at this time, and you don't want anyone other than its developers testing it yet, then it probably isn't a good idea to package it yet. My goal was purely to seek a GTK+3 version of Pidgin, and some searching turned up the Pidgin 3.0 branch.
It's not that we're against feedback or people using it, it's that there shouldn't be a GA or anything. At best it's alpha level right now. If there was a beta or an rc or something, then sure by all means package away :) Gotcha. It's unfortunate it's taken this long, but it is what it is now. We're slowly grinding through it, but it's going to be a bit yet. Thanks,
It's not that we're against feedback or people using it, it's that there shouldn't be a GA or anything. At best it's alpha level right now. If there was a beta or an rc or something, then sure by all means package away :) Gotcha. It's unfortunate it's taken this long, but it is what it is now. We're slowly grinding through it, but it's going to be a bit yet. Thanks,
There was a new release at the end of September, but the developers are still labeling it as "pre alpha": https://discourse.imfreedom.org/t/pidgin-3-0-experimental-4-2-93-0-has-been-released/309 It actually uses gtk4 instead of gtk3. Thank you, Jeremy Bícha
I would certainly install that from Debian experimental, if available. But no time to help with that, sorry.
A few days ago, Pidgin 2.94.0 was released as yet another "pre-alpha" [1]. The Pidgin developers have consistently released new snapshot builds every 3 months since the beginning of 2025. I read through the release notes and I installed Pidgin 2.94.0 from Flathub Beta. Here are some notes. 1. IRC is the only protocol working so far. I don't know when XMPP will be ready. People who need XMPP could try dino-im instead. 2. Pidgin's core will only have open protocols (IRC, XMPP, Matrix, etc.). Not-so-open protocols will need to be separate plugins. I don't think work has started on Matrix yet. I am guessing it's too early for there to be plugins for Pidgin 3 yet. 3. Everything using libpurple will need to make major changes [2]. Developers suggested they may eventually add a compatibility layer to make it easier for things already using libpurple, but not until the API is more finalized. 4. There are several new external libraries that will need to be packaged. 5. Finch, a command line version of Pidgin, is no longer provided. 6. The Pidgin developers recommend that this version of Pidgin not be packaged for end users yet. The Debian GNOME team have announced [3] their goal of removing GTK2 for Forky. Based on my experience landing gimp 3 for Trixie which also broke everything compiled against gimp 2, I recommend letting pidgin be removed from Testing. File RC bugs against everything built against pidgin and libpurple. Package transitions technically only happen when updating something in Testing to something else. Since Pidgin won't be in Testing, there is no formal Pidgin 3 transition needed. I expect we have about a year or so before Forky starts freezing for the Debian 14 release in 2027. I think it would be good to get pidgin 3 into Experimental in the next few months, even if we intend to wait until later in the year to get it into Unstable. [1] https://discourse.imfreedom.org/t/pidgin-3-0-experimental-5-2-94-0-has-been-released/338 [2] https://docs.imfreedom.org/purple3/migrating.html [3] https://lists.debian.org/debian-devel/2026/01/msg00090.html Thank you, Jeremy Bícha
We (upstream) are EXPLICITLY asking packagers to not package this for the time being. It has been in every single release announcement. From the release announcements that I keep copy/pasting.. at all, and there are so so many bugs. As such we are asking that packagers please *do not package* this for your users yet as the potential support requests will be too much for us to handle at this time.
For those of you that don't know, I am the lead developer of Pidgin. As I stated a moment ago, I am EXPLICITLY pleading with packagers to not package these releases for end users yet. I do not have the time to be able to field user requests and bugs for stuff that is incomplete and not intended for general releases. 1. There are incomplete bonjour and xmpp plugins in the main install that you can't see because they're hidden behind the "developer mode" setting. 2. Like purple2, all protocols are plugins. If you're referring to third party protocols, they're not different and I have a twitch[1] plugin that works pretty well and is being used to finish wrapping up some of the more complicated modern apis. The recommendation for the twitch protocol plugin is to use a meson dev environment from a pidgin3 build. 3. As for package transitions, everything is new, the so names for purple2 is purple, and purple3 is purple3. There is no compatible transition, similar to the python 2 / 3 transition from years ago. So removing from testing is already pointless except that it will create more work for me personally because users are going to start trying to compile pidgin themselves, run into dependency issues, and will refuse my suggestions to use the flatpak for whatever reasons and everyone has a bad time. 4. hasl was already started here [2] there were additional ITPs for the others but no work has been done on them yet as far as I know. 5. Finch is dead until someone steps up to maintain finch and/or libgnt as we do not have the resources to continue maintaining them. 6. Yep, and here we are talking about it anyways... We've been anticipating that GTK2 will be removed from all distros most likely this year. We have been busting our asses to get something together so that Pidgin can remain in distros, but we just do not have the resources. If you look at the last release, you will see that absolutely everything came from me personally, if you look at the releases before that you'll see that I am the main driving factor. When you force me to respond to things I've already asked you not to do it cuts into that precious time and slows things down. And I'll reiterate, removing from testing *WILL* increase my workload. We've seen it from Ubuntu LTS's that had old buggy versions to Whonix and everywhere in between. Users refuse to use a flatpak and instead attempt to compile themselves and then require a ton of support. Which will be even more so if `apt get build-dep` isn't an option because it's been removed from testing. Regardless, you are going to do what you're going to do and I can not control that. But I am pleading with you to please not make my burnout (which has been mentioned in the release announcements which you claim to have read) any worse. [1] https://keep.imfreedom.org/grim/purple-spasm/file/default/README.md [2] https://salsa.debian.org/debian/hasl
I'm not sure why you would want to do this. It doesn't help your goal to remove GTK2 (since as per your plan, you'd drop pidgin2 and libpurple and their dependencies from testing prior anyway); whilst I'm glad Pidgin3 is being developed, as you know, it's in no way a replacement for Pidgin2 yet, so it doesn't service our users of Pidgin2 to pretend otherwise; and packaging it -- even in experimental -- is against the explicit wishes of upstream.
Hi,
Am Mon, Jan 12, 2026 at 08:59:22AM +0000 schrieb Jonathan Dowland:
Given this discussion does not have finished yet, I wonder whether we
should decrease severity of the bugs filed against pidgin-* packages
(like #1125050 against pidgin-awayonlock) from serious to important.
Kind regards
Andreas.
I don't want to make you feel pressured, but I acknowledge that my work to try to remove gtk2 from Debian is unavoidably adding pressure to maintainers of gtk2 apps. I am trying to be particularly sensitive about Pidgin. It is the only gtk2 app other than the Debian Installer that is still in Testing and not marked for autoremoval from Testing because of the gtk2 transition. Do you think that Pidgin 3 might be usable for IRC and XMPP by mid-2027? It's my opinion that those are the 2 key protocols supported by Pidgin 2 that are of most interest to Debian users. Debian does have some other IRC and XMPP apps though, so if Pidgin could only handle one of those, it might still work. Thank you, Jeremy Bícha
Sorry somehow this got lost in my inbox. At any rate, I would expect us to have a 3.0 version that's acceptable for users by mid 2027. We're trying to make our next experimental release which is due 2026-03-31 to actually be Alpha 1. The difference of the Alpha title is that we're saying the protocol API shouldn't be changing much but we're still not guaranteeing API stability. This is basically a signal to third party developers that they can start working on stuff even though there are already a few experimenting. As for XMPP, it'll get there when it gets there. I'm the primary developer for the entire project and with gtk 2 getting removed everywhere I have to focus on getting everything else ready and XMPP is a very complicated protocol to implement. It's still on the list of course, but it's being pushed back for Zulip which is another open source protocol that is much easier to implement. But basically, the goal right now is to stabilize APIs for third party protocol developers (nearly there), then focus on polishing the UI, then releasing for end users.
Yes, I read your most recent State of the Bird [1] this week and the graphic makes it clear that you're doing nearly all the work. I'm sorry. Thank you for your reply. [1] https://discourse.imfreedom.org/t/state-of-the-bird-january-2026/358 Jeremy Bícha