Hi guys,
I just checked the Jenkins and I could see that there are some issues building the X2Go Client heuler packages for bullseye. Looks like the problem is in qt4 build dependencies, which is not available in bullseye anymore. I don't want to get involved in the packaging process, but I think it's very important to have the nightly builds working for debian testing. What do you think about it?
regards, Alex
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
Hi Alex,
On Mo 26 Apr 2021 18:10:25 CEST, Oleksandr Shneyder wrote:
Hi guys,
I just checked the Jenkins and I could see that there are some issues building the X2Go Client heuler packages for bullseye. Looks like the problem is in qt4 build dependencies, which is not available in bullseye anymore. I don't want to get involved in the packaging process, but I think it's very important to have the nightly builds working for debian testing. What do you think about it?
regards, Alex
I think that the DEB based package builds should switch to Qt5 builds.
I'll check, if that also works for Debian 9 builds. If so, I'll do the
switch over.
@Mihai: unless you have an outstandingly better idea.
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
- On 4/27/21 7:58 PM, Mike Gabriel wrote:
I think that the DEB based package builds should switch to Qt5 builds.
I'll check, if that also works for Debian 9 builds. If so, I'll do the
switch over.@Mihai: unless you have an outstandingly better idea.
I'll switch the deb builds over to Qt5 for bullseye+ within the next few days. Too tired to do that today.
Mihai
- On 4/28/21 1:58 AM, Mihai Moldovan wrote:
I'll switch the deb builds over to Qt5 for bullseye+ within the next few days. Too tired to do that today.
Started working on it.
I'll want to write up a small preprocessor utility to handle this in a nicer way.
Will hopefully get that done in the next few days.
Mihai
Hmm, afaics the only thing that needs to be done is changing the link from debian-qt4 to debian-qt5, depending on the distribution. Or am I missing something crucial here?
Uli
Mihai Moldovan <ionic@ionic.de> schrieb am So., 2. Mai 2021, 14:28:
- On 4/28/21 1:58 AM, Mihai Moldovan wrote:
I'll switch the deb builds over to Qt5 for bullseye+ within the next few days. Too tired to do that today.
Started working on it.
I'll want to write up a small preprocessor utility to handle this in a nicer way.
Will hopefully get that done in the next few days.
Mihai
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
Hi Mihai, hi Uli,
Am Sonntag, 2. Mai 2021 schrieb Ulrich Sibiller:
Hmm, afaics the only thing that needs to be done is changing the link from debian-qt4 to debian-qt5, depending on the distribution. Or am I missing something crucial here?
Uli
Mihai Moldovan <ionic@ionic.de> schrieb am So., 2. Mai 2021, 14:28:
- On 4/28/21 1:58 AM, Mihai Moldovan wrote:
I'll switch the deb builds over to Qt5 for bullseye+ within the next few days. Too tired to do that today.
Started working on it.
I'll want to write up a small preprocessor utility to handle this in a nicer way.
Will hopefully get that done in the next few days.
Mihai
-- Gesendet von meinem Sailfish Gerät
Hi Mihai, hi Uli,
for the DEB builds, switching the symlink is all that is needed.
I am also pretty sure that all DEB distro versions we support should be able to handle Qt5 builds just fine.
Please note that Qt5 has already been abondened by Trolltech and only receives security support by the KDE team.
That is, Qt5 is cold coffee already, Qt4 is a dried out puddle. Don't waste to much time switching between Qt4 and Qt5.
Mike
Am Sonntag, 2. Mai 2021 schrieb Ulrich Sibiller:
Hmm, afaics the only thing that needs to be done is changing the link from debian-qt4 to debian-qt5, depending on the distribution. Or am I missing something crucial here?
Uli
Mihai Moldovan <ionic@ionic.de> schrieb am So., 2. Mai 2021, 14:28:
- On 4/28/21 1:58 AM, Mihai Moldovan wrote:
I'll switch the deb builds over to Qt5 for bullseye+ within the next few days. Too tired to do that today.
Started working on it.
I'll want to write up a small preprocessor utility to handle this in a nicer way.
Will hopefully get that done in the next few days.
Mihai
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
-- Gesendet von meinem Sailfish Gerät
* On 5/2/21 2:27 PM, Mihai Moldovan wrote:
I'll want to write up a small preprocessor utility to handle this in a nicer way.
Will hopefully get that done in the next few days.
Finally got it all ready and, as far as I can tell, working right now. I've created a preprocessing script (replacing @@MARKERS@@) and a simple condition-based preprocessor written in Perl for handling this. Debian Bullseye and higher will use Qt 5, older releases stay on Qt 4. Ubuntu 20.04 and higher will use Qt 5, older release stay on Qt 4. I can easily extend this solution to Qt 6 once it hits distributions, so that's good. The debian/control will now be autogenerated by our build system, but also must be manually synced to the build-master-qt{4,5} branches for Launchpad (only). A README file with instructions is provided. That's a bit inconvenient, but Launchpad doesn't allow "run"-type hooks in their recipes (yet) and they require a working control file in the main build branch, so that was the only generic solution I could come up with. Due to this, I had to split the nightly builds into two recipes on Launchpad. The old one is set to manual mode - please don't trigger builds there by accident. Now that the .deb-based systems are done, I'll continue with the RPM-based ones, probably tomorrow. That should be a lot easier, since spec files are much more powerful compared to the static Debian files. Also a bit of polishing, but that's non-critical. Mihai
Great, Mihai, thank you for your work. regards, Alex Am 12.05.21 um 17:37 schrieb Mihai Moldovan:
- On 5/2/21 2:27 PM, Mihai Moldovan wrote:
I'll want to write up a small preprocessor utility to handle this in a nicer way.
Will hopefully get that done in the next few days.
Finally got it all ready and, as far as I can tell, working right now.
I've created a preprocessing script (replacing @@MARKERS@@) and a simple condition-based preprocessor written in Perl for handling this.
Debian Bullseye and higher will use Qt 5, older releases stay on Qt 4.
Ubuntu 20.04 and higher will use Qt 5, older release stay on Qt 4.
I can easily extend this solution to Qt 6 once it hits distributions, so that's good.
The debian/control will now be autogenerated by our build system, but also must be manually synced to the build-master-qt{4,5} branches for Launchpad (only). A README file with instructions is provided. That's a bit inconvenient, but Launchpad doesn't allow "run"-type hooks in their recipes (yet) and they require a working control file in the main build branch, so that was the only generic solution I could come up with.
Due to this, I had to split the nightly builds into two recipes on Launchpad. The old one is set to manual mode - please don't trigger builds there by accident.
Now that the .deb-based systems are done, I'll continue with the RPM-based ones, probably tomorrow. That should be a lot easier, since spec files are much more powerful compared to the static Debian files. Also a bit of polishing, but that's non-critical.
Mihai
-- ----------------------------------------------------------- Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461 Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973 -----------------------------------------------------------
- On 5/13/21 12:37 AM, Mihai Moldovan wrote:
Now that the .deb-based systems are done, I'll continue with the RPM-based ones, probably tomorrow. That should be a lot easier, since spec files are much more powerful compared to the static Debian files. Also a bit of polishing, but that's non-critical.
That took a lot longer than expected.
I had to update mock configuration files for newer Fedora versions (mostly to update the Rawhide ones) and then it turned out that the RPM version on the stretch-based package builder was too old.
That meant that I had to backport the rpm version from unstable and rebuild all dependent packages like dnf, libsolv etc.
With that, newer Fedora versions started building again, but older releases, like EPEL 6 and 7, which are yum-based, started failing on downloading build dependencies.
I then started looking into replacing yum-builddep with the dnf-provided yum-builddep wrapper, but soon found out that this didn't work either. dnf-utils, even when invoked as yum-builddep with an installroot parameter, only searches for dnf.conf - first within the installroot, then within the main system, if the installroot does not contain this file. Thus, I went ahead and patched dnf to add a --yumcompat flag which is automatically passed for yum-compat wrappers like yum-builddep and which prefers yum.conf over dnf.conf, with a fallback to the latter.
This initially seemed to work for downloading the build dependencies, but failed later while installing them through yum, which is not easily replaceable.
In the end, it turned out that I forgot to backport a Python 2 compatibility patch to the rpm package (since upstream RPM dropped Python 2 support for good), after which yum started working again.
With a few more spec file changes, we're now building against Qt 5 on RPM-based platforms which do not support Qt 4 any longer.
I'll still have to work on the Windows and OS X/macOS builds, but probably more importantly, will have to port the changes to other packages as well, like PinEntry-X2Go (which needs proper rebasing against a newer upstream version, I figure), X2GoAdminCenter (which is... actually quite dead anyway) and X2GoDesktopSharing.
Mihai
Hi folks,
On Mo 26 Apr 2021 18:10:25 CEST, Oleksandr Shneyder wrote:
Hi guys,
I just checked the Jenkins and I could see that there are some issues building the X2Go Client heuler packages for bullseye. Looks like the problem is in qt4 build dependencies, which is not available in bullseye anymore. I don't want to get involved in the packaging process, but I think it's very important to have the nightly builds working for debian testing. What do you think about it?
regards, Alex
today I have taken a look at X2Go HTML Client and X2Go KDrive. I
worked on several topics:
- package x2gowswrapper, x2gowebrpc and x2gohtmlclient (not fully done, yet)
- fix FTBFS of x2gokdrive (Debian, Ubuntu probably as well)
- fix FTBFS of x2gokdriveclient against older Qt5 (Debian stretch)
Greets, Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Hello Mike and Alex
@Alex: Can you please add licence files to original project?
On 2021-06-14 15:14 1, Mike Gabriel wrote:
- package x2gowswrapper, x2gowebrpc and x2gohtmlclient (not fully done, yet) As I seen, that Oleksandr has created this packages, I wanted to try it out and was beginning to packaging this for debian: https://salsa.debian.org/debian-remote-team/x2gohtmlclient https://salsa.debian.org/debian-remote-team/x2gowebrpc https://salsa.debian.org/debian-remote-team/x2gowswrapper
Right now is unclear which license is used 8) A little bit sloppy packages are available under: https://debian-remote-team.pages.debian.net/-/x2gohtmlclient/-/jobs/1688304/... https://debian-remote-team.pages.debian.net/-/x2gowebrpc/-/jobs/1688292/arti... https://debian-remote-team.pages.debian.net/-/x2gowswrapper/-/jobs/1688252/a...
It's not tested right now.
Best Regards, Juri Grabowski
On Mi 16 Jun 2021 11:48:33 CEST, x2go-dev wrote:
Hello Mike and Alex
@Alex: Can you please add licence files to original project?
On 2021-06-14 15:14 1, Mike Gabriel wrote:
- package x2gowswrapper, x2gowebrpc and x2gohtmlclient (not fully done, yet) As I seen, that Oleksandr has created this packages, I wanted to try it out and was beginning to packaging this for debian: https://salsa.debian.org/debian-remote-team/x2gohtmlclient https://salsa.debian.org/debian-remote-team/x2gowebrpc https://salsa.debian.org/debian-remote-team/x2gowswrapper
Right now is unclear which license is used 8) A little bit sloppy packages are available under: https://debian-remote-team.pages.debian.net/-/x2gohtmlclient/-/jobs/1688304/... https://debian-remote-team.pages.debian.net/-/x2gowebrpc/-/jobs/1688292/arti... https://debian-remote-team.pages.debian.net/-/x2gowswrapper/-/jobs/1688252/a...
It's not tested right now.
Best Regards, Juri Grabowski
Done! Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
-
Mihai Moldovan -
Mike Gabriel -
mike.gabriel＠das-netzwerkteam.de
-
Oleksandr Shneyder -
Ulrich Sibiller -
x2go-dev＠jugra.de