Debian removes FPC/Lazarus

[Zvoni]

Xfce has committed to a totally Wayland model, Enlightenment was an early Wayland convert. I don't know about Cinnamon, Budgie etc. 

Cinnamon has declared Wayland as "experimental"
Have a guess what they use as Display-Server....

from: dbannon on 23-02-2026, 00:43:38

    I don't know about Cinnamon, Budgie etc.

Do they have users? Seriously, who cares?

Considering Cinnamon is the Standard DE for Linux Mint, and Mint is one of the most used Ubuntu-derivatives....

[dbannon]

.... because Wayland did not provide a way to specify positions until a few weeks ago and even then it's only part of the protocols for now, so essentially no released compositor and no released framework supports it.

Further, I get the impression that this xx-zones is 'controversial', the Wayland Puritans publicly hate it.

I don't understand that attitude but ignoring it will not help ! I just don't understand why positioning on screen is offensive to some people ??

Davo

[lproven]

This is because they are dropping support for gtk2 and both FPC and Lazarus (appear) to depend on the much out of date gtk2 !

FPC is not alone with this problem.

Multiple other programs in Debian use Gtk2 as well -- a partial list (in English, despite the URL) is here:

https://prohoster.info/en/blog/novosti-interneta/v-debian-14-namereny-prekratit-postavku-gtk2

The Ardour digital audio workstation is in active development -- the project recently released Ardour 9.2 -- and it still uses Gtk2:

https://ardour.org/faq.html#toolkit

As a result, the Ardour team is maintaining its own fork of Gtk2 called Ytk.

Perhaps it would be possible, as a first step, to switch to Ytk instead? That would be a quick fix, while a more complete or thorough one is investigated.

[dbannon]

...
Perhaps it would be possible, as a first step, to switch to Ytk instead? That would be a quick fix, while a more complete or thorough one is investigated.

While thanks for the suggestion, no, I really don't think that would be good for FPC/Lazarus. Truth is we are not really dependent on gtk2. We could easily use Qt5 or Qt6 right now and Gtk3 is not too bad already.

There are, IMHO, two issues -

• An apparent but not real dependency in FPC on gtk2. FPC has a dir, /packages/gtk2 that as some gtk2 and other libary bindings that, unfortunately Debian assumes was some gtk2 build dependency. Its not and never was. That has been fixed, sort of.
• Lazarus keeps shipping, in its own official packages,  gtk2 product. That sends a signal that Lazarus is dependent on gtk2, only makes gtk2 apps, needs gtk2 to run and so on. Again, wrong, Lazarus can, on *nix, use and make Qt5. Qt6 and, almost, gtk3.

In both cases, political not technical. The relevant bodies need to review certain decisions.

Lazarus could, as a first step, move the libpango and libpangocairo bindings out of its gtk3 tree and into somewhere more (*nix) general because Qt5 and Qt6 apps need them, currently they use the ones that exist in that FPC gtk2 directory that is upsetting Debian so much.

Davo

[Thaddy]

@dbannon

A good write up except I would not mention neither Qt5 nor GTK3 as possible solutions. Both are already too old in the scheme of things.
For the short term I would concentrate on a Qt6 build for Lazarus and repackaging as per your analysis for both FPC and Lazarus.
The FPC repackaging should be in 3.2.4. if possible in this case. (port and a back-port)

Qt5 and GTK3 carries the risk of development investment in widgetsets that most already consider legacy.

An important side note is PascalDragon's remark about the recent protocol definition in Wayland that should finally handle old style windowed interfaces.

[Fred vS]

An important side note is PascalDragon's remark about the recent protocol definition in Wayland that should finally handle old style windowed interfaces.

Great, that's all that's left to fix: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277

 

[vfclists]

Smile 

This topic made it to Hacker News - https://news.ycombinator.com/item?id=47149582

[PascalDragon]

For the short term I would concentrate on a Qt6 build for Lazarus and repackaging as per your analysis for both FPC and Lazarus.

The problem with Qt is that an additional dependency is required in the form of the qtXpas library.

The FPC repackaging should be in 3.2.4. if possible in this case. (port and a back-port)

There will be no repackaging.

An important side note is PascalDragon's remark about the recent protocol definition in Wayland that should finally handle old style windowed interfaces.

I'll only believe that when major compositors implement that protocol.

[zeljko]

The problem with Qt is that an additional dependency is required in the form of the qtXpas library.

Distro have such package, I don't see any problem because of libQtXPas dependency. It is better to have a sparrow in your hand than a dove on a branch.

[dbannon]

Distro have such package, I don't see any problem because of libQtXPas dependency. It is better to have a sparrow in your hand than a dove on a branch.

They do indeed but its not quite a simple as that. If you, the developer, are using a newer distro and you don't plan to distribute working binaries, it is that simple. But that is not usually the case. If you have customers or users that might be using a different distro or a different aged distro, problems. Lets take Ubuntu of example, I don't use Ubuntu but its version numbers help this discussion because they define its release date.

• The most recent (LTS) Ubunu is 24.04, it has usable libqt5pas and libqt6pas in its repo. Works fine.
• The previous 22.04 does not have usable libqt5pas nor any libqt6pas. Can be built and runs fine.
• The 20.04 Ubuntu has neither, a built libqt5pas can be built and works, libqt6pas cannot.

Now, U20.04 became unsupported last year but is still covered by various Ubuntu Pro plans until, wait for it, 2035 !

The problem is worse with Debian and its direct derivatives, a slightly slower release cycle. I use Debian bookworm, under LTS until 2028. It has libqt5pas 2.6+2.0.8+dfsg-2, no libqt6pas. That libqt5pas will not work with apps made using current Lazarus. A new one, and a libqt6pas can be built and work fine.

Remember please that a major proportion of Linux distros are derivatives, one way or another of Debian.

End user do not cope well with these 'extras' !

Davo
 

[robert rozee]

Distro have such package, I don't see any problem because of libQtXPas dependency. It is better to have a sparrow in your hand than a dove on a branch.

[...]

• The most recent (LTS) Ubunu is 24.04, it has usable libqt5pas and libqt6pas in its repo. Works fine.
• The previous 22.04 does not have usable libqt5pas nor any libqt6pas. Can be built and runs fine.
• The 20.04 Ubuntu has neither, a built libqt5pas can be built and works, libqt6pas cannot.
[...]
The problem is worse with Debian and its direct derivatives, a slightly slower release cycle. I use Debian

bookworm, under LTS until 2028. It has libqt5pas 2.6+2.0.8+dfsg-2, no libqt6pas. That libqt5pas will not work with apps made using current Lazarus. A new one, and a libqt6pas can be built and work fine.
[...]
End user do not cope well with these 'extras' !

many thanks Davo, you have answered some of the questions i asked back in Reply #77:

[...] does Qt6 provide backward compatibility with Qt5? ie, will a machine with Qt6 on it be likely to also have Qt5 present, or a Qt5 'compatibility layer'?

another question - at the moment, if i give someone an ELF binary built for GTK2 they can (based on feedback i've received) just run it without any problems - they do not need to install anything else. does the same hold for an ELF binary i've built for Qt5? or do i also need to have them install libqt5pas.so? or is libqt5pas.so always present in distros that out-of-the-box have Qt5 installed? [...]

for me, this renders supporting Qt/Qt5/Qt6 of absolutely NO use. my users expect to be sent an ELF binary that just works, without need for any installation process. they lack the ability to determine if extra libraries are installed or to go on to find and install them; as it is they can only just manage to flag a binary as being executable!

why can the functionality provided by libQt5pas.so and/or libQt6pas.so not be compiled into an application's ELF binary?


cheers,
rob   :-(

[AmatCoder]

Maybe I am missing something but you can build libQt6Pas statically...

[zeljko]

For static library usage you must buy Qt license AFAIR.

[MarkMLl]

Distro have such package, I don't see any problem because of libQtXPas dependency. It is better to have a sparrow in your hand than a dove on a branch.

They do indeed but its not quite a simple as that. If you, the developer, are using a newer distro and you don't plan to distribute working binaries, it is that simple. But that is not usually the case. If you have customers or users that might be using a different distro or a different aged distro, problems. Lets take Ubuntu of example, I don't use Ubuntu but its version numbers help this discussion because they define its release date.

There is also an issue in that the shim library is only good for a certain range of Lazarus versions. If a developer compiles up a (fairly wide) range for application testing, at some point compatibility between the LCL and libQt#Pas breaks and neither the IDE nor applications will work with Qt.

These days it's obviously possible to work round that using some form of container, but it's unfortunate and argues against libQt#Pas being a panacea.

MarkMLl

[Handoko]

Qt Community Edition is only for open source projects, or you have to purchase the license. I've just checked the price, the license for small business is $ 618 per year.