davidbannon / libqt6pas Goto Github PK

This library needs to be updated

This library needs to be updated

This library needs to be updated

This library needs to be updated

This library needs to be updated

On Enterprise Linux 9 (RHEL, AlmaLinux, Rocky, etc) GLIBC_2.35 is not available.

$ sudo dnf install ./libqt6pas6-2.0-2.x86_64.rpm 
Last metadata expiration check: 1:14:08 ago on Fri 18 Nov 2022 09:17:14 PM CST.
Error: 
 Problem: conflicting requests
  - nothing provides libm.so.6(GLIBC_2.35)(64bit) needed by libqt6pas6-2.0-2.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

EL9 is glibc-2.34, not glibc-2.35

$ rpm -qf /usr/lib64/libm.so.6
glibc-2.34-40.el9.x86_64

https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/d115ec0399a1b57174224c5535d885421591c41e

This library needs to be updated

This library needs to be updated

This library needs to be updated

This message last in closed issue #3

OK Salvador, I think we are looking at this the wrong way. Its silly trying to automate the build - package workflow because it needs to be manually synced with the main in gitlab first. When I do that, manually, its not that hard to generate the binary and dead easy to package. The problem that we are ignoring is, Z is changing the interface, twice in the last few days and I am not spotting that.

A far better approach, IMHO, would be for your workflow to generate a new binary, ie the library, every time he makes a change to the Qt6Pas.Pro file. Now, people who must have the latest can get the library themselves, its the output of your workflow. If they are playing at the cutting edge, its not that hard to manually install the library, I have detailed instructions on the site here. So, thats useful right away.

And, maybe your workflow, at the end, sends me an email saying, "Salvador's workflow has generated a new binary" and I'd either do the packaging manually or, we'd trigger a separate, different workflow that can build the packages.

Sounds like you can make the binary already, all we need to do is figure out how to get your workflow access to the necessary files and know when it needs to do its stuff. In the old days, I'd just wget Qt6Pas.Pro to my server, check its checksum and if its changed, download just the cbindings directory and compile away.

Easy to script, is it easy for you to turn into a github workflow ? Maybe run every 2 hours ?

RE your problems with the RPM packaging, I think I need to rewrite that and remove the dependency on alien. Its days are over. Should be easy but right now, we should concentrate on the other end of the process.

Davo

This library needs to be updated

This library needs to be updated

This library needs to be updated

This library needs to be updated

This library needs to be updated

QFontDatabase constructor and destructor unavailable in qfontdatabase_c.h :
C_EXPORT QFontDatabaseH QFontDatabase_Create();
C_EXPORT void QFontDatabase_Destroy(QFontDatabaseH handle);
This do not permit to build Typhon 8.x on Linux (Mint 21.x with QT 6 for example).

This library needs to be updated

This library needs to be updated

This library needs to be updated

This library needs to be updated

This library needs to be updated

This library needs to be updated

https://forum.lazarus.freepascal.org/index.php/topic,52912.msg460012.html#msg460012

@davidbannon

This library needs to be updated

This library needs to be updated

This library needs to be updated

libqt6pas-dev-2.2-1.x86_64.rpm
libqt6pas-dev_2_2-1_amd64.deb
libqt6pas6-2.2-1.x86_64.rpm
libqt6pas6_2_2-1_amd64.deb
libqt6pas_6_2_2-1_amd64.tar.gz

Usually I read recommendations to name DEB packages like this:
cudatext_1.177.0.0-1_gtk2_amd64.deb

Here you see version number DOT separated, and version is separated from name by underscore, and from widgetset name , and from CPU.

@davidbannon

This library needs to be updated

This library needs to be updated

This library needs to be updated

This library needs to be updated