A better way to make these packages about libqt6pas HOT 16 CLOSED

I have pushed up a first cut at a package script that does not use alien. Works for main library, -dev needs work.
Davo

from libqt6pas.

Typically for something like this building the RPM (well, any package) in a github actions (and publishing them) would likely only occur on a merge to a specific release branch.

from libqt6pas.

I currently use tags rather than branches because of the simplicity of the overall project. Z will update the third stanza of the version number (as recorded in Qt6Pas.Pro) with every change to the interface. So, each and every time, its a new release. Over time, it will settle down of course ...

Its important to get it right so people do use/experiment with the new interface, only way to find bugs ! So, anything to make that easier is a good idea.

Davo

from libqt6pas.

In my opinion, the workflows can be two.

First (run every 2 hours? 6 hours? I must see github docs to find better timing):

1. Get new version of libqt6pas from gitlab lazarus
2. (only if there are changes) Commit changes in this repo
3. (only 2 & if version number changes) Tag with version number from Qt6Pas.Pro

Second (every new tag):

1. Build libqt6pas
2. Make packages (optional)
3. Add liqt6pas files in tag/release
4. Email to maintainer with link to tag/release and logs

What do you think?

from libqt6pas.

I always aim for the simpler solution to any problem. Now, if Z makes detail changes in the cpp source we really don't need do anything, he is working on something but its not finished. Its only when he changes the Qt6Pas.Pro file with a new release number that we (can or) need to do anything. So, its just -

• download Qt6Pas.Pro, read the version number, compare it to previous one or, if no previous one just write it to some where locally. Maybe its a just a file in the repo ?
• If the numbers compared above don't match, then update the local version number and download the cbindings dir, build the library.

Thats all IMHO, we don't need to keep a local copy of the cbindings contents, we only need it when we are building. So, no need to do any comparing. We don't want to build a new library when Z makes arbitrary changes to the cpp/h code, because we cannot give it a new number, and we should not change the contents unless it gets a new number.

I am not sure if we need worry about making a new release each time, maybe just poke the new library into the same release repo. Flush out the old ones, I am guessing thats technically possible in a workflow ?

Thoughts ?

Davo

from libqt6pas.

Its only when he changes the Qt6Pas.Pro file with a new release number that we (can or) need to do anything.

No problem. Indeed, those who want to see the history of changes can see on gitlab.

I am not sure if we need worry about making a new release each time, maybe just poke the new library into the same release repo.

It wouldn't hurt to have old versions of the compiled library as well. Just right for any regression tests and such.

from libqt6pas.

Yes, I like the idea of enabling regression testing but if Z makes too many changes, the dir will soon look confusing if they are all in one.

And, on that topic, reckon we can do ARM64 the same way ?

Davo

from libqt6pas.

Actually, we might need the source locally, I am watching new packages submitted to Debian (because I'm updating my tomboy-ng there) and saw a pacman-package-manager go past. So, with that, we could add pacman (ie Arch Linux and friends) but pacman insists on getting the source itself ....

Davo

from libqt6pas.

Yes, I like the idea of enabling regression testing but if Z makes too many changes, the dir will soon look confusing if they are all in one.

I mean manual regression test. And the github release page doesn't seem to confuse things much.

And, on that topic, reckon we can do ARM64 the same way ?

I've never tried to compile anything for arm.

Actually, we might need the source locally, I am watching new packages submitted to Debian (because I'm updating my tomboy-ng there) and saw a pacman-package-manager go past. So, with that, we could add pacman (ie Arch Linux and friends) but pacman insists on getting the source itself ....

In this case, however, it is on the official topic. It shouldn't be Lazarus Team dealing with it (make official package for distro)?

from libqt6pas.

I mean manual regression test.
yep, so do I. I think we should leave all the libraries there but replace the packages.

And the github release page doesn't seem to confuse things much.
The extreme case ?
If we end up with 50 releases on the same page, that would be confusing IMHO, three or four architectures. Thats 150 - 200 files.
But if we do the packages in the same dir, now we have 2 debs, 2 rpms, 2 pacman, one of each .tar.gz, 450 !

Hmm, we could make windows DLLs and MacOS dynamics as well. Today its a library, tomorrow, we rule the world ! OK, slow down a bit ....

I've never tried to compile anything for arm.
Easy, same code, just has a request that it run on an arm machine at the top of the yaml file. So, long term, i386, x86_64, arm64, armhf ? I think the two 32bit ones are pretty much redundant but, who knows ? The build is automatic, getting the packaging right is tedious but once done, OK.

...... but pacman insists on getting the source itself ....

In this case, however, it is on the official topic. It shouldn't be Lazarus Team dealing with it (make official package for distro)?
No, not all of Lazarus code, just the cbinding dir, the pacman process is that we point to a on line repo, quote the tag and pacman goes and gets it. It pretty slick but needs to build it itself, so in this case, slow. I build pacman packages for my project but do so, manually, on a Arch VM. So, a nuisance because I can build all the other the x86_64 and arm, linux and windows all with one script.

But, for us now, pacman is a low priority. Pacman download is about 4% of my last release.

Davo

from libqt6pas.

I just now built up to date with git libqt6pas and the RPMs on AlmaLinux 9.1 on Fedora 37. No issues.

No qt6 for AlmaLinux 8.7, so I tried to build up to date with git libqt5pas and the RPMs. Once again, no issues.

So building the rpm packages is working well.
They all installed fine as well on all 3 platforms.

For libqt6pas the package-lib script is marked executable in git. For libqt5pas it is not. Not a big deal though.

As far as Pacman... I switched over what was remaining of my Archlinux installs summer of 2022 to Almalinux. So I won't be affected by that. 4% is low... but 4% of what total number of downloads?

When I did use Arch I was depending on this the libqt5pas package though.

from libqt6pas.

Ah, useful feed back !
I have no interest in a paywall, software wants to be free ! But, until now, no one has asked for a pacman package. They are actually pretty easy to make, I make a pacman for my own app, tomboy-ng. Only difficulty is that it has to be made on a pacman enabled machine so cannot do it in one one script like I do for the other ones.

The thing holding Qt6 back right now is bugs in the available Qt6 libraries themselves, see https://forum.lazarus.freepascal.org/index.php/topic,61295.0.html

I note that Debian Bookworm now has Qt6 6.4.2, that could be a game changer IMHO, I'll test on it later today !

I am guessing that Arch also have a new (or newest) Qt6 ? Have you tested for the SaveDialog delay problem ?

Davo

from libqt6pas.

Ah, useful feed back ! I have no interest in a paywall, software wants to be free ! But, until now, no one has asked for a pacman package. They are actually pretty easy to make, I make a pacman for my own app, tomboy-ng. Only difficulty is that it has to be made on a pacman enabled machine so cannot do it in one one script like I do for the other ones.

As I had noted (before removing it from my post) that was in jest, a friendly jab at Arch (Since I had used it for over 14 years and finally replacing my use of it with AlmaLinux last year I obviously did appreciate many of its qualities, and still respect those, and I would not rule out using it for specific aarch64 or risc-v projects in the future).

I am guessing that Arch also have a new (or newest) Qt6 ?

https://archlinux.org/packages/extra/x86_64/qt6-base/ 6.4.2 as of this writing...

Have you tested for the SaveDialog delay problem ?

I have not tested it yet.

from libqt6pas.

Sadly, my tests earlier today indicate the 6.4.2 does NOT solve the problem. I am unsure of just what is happening there, it seems unlikely that Qt would keep shipping a product with this same bug but zeljko did seem sure it was a 6.2 problem.
Its a blocker as I see it....
Davo

from libqt6pas.

I just tried it now with libqt6pas6-6.2.5-1 and qt6 6.3.1.
The delay on my system is insignificant.

from libqt6pas.

These problems all seem to be a thing of the past.
D

from libqt6pas.