Misc deployment cleanup and improvements

[AaronDMarasco]

Misc improvement like logfiles including what distro was built. Also actually run on Py3.6; apparently before it claimed that but rally needed 3.8.

This also includes an aborted CentOS 8 port; that did a lot better than C7, but still failed:

CMake Error at src/libs/ComponentSystem/CMakeLists.txt:29 (cmake_policy):
  Policy "CMP0077" is not known to this version of CMake.

[fizzyade]

All applied, I had to modify a couple of files as I switched to using std::random.

Triggered a TeamCity build and all deployments worked correctly.

Thanks for your continued work on this.

[AaronDMarasco]

No problem!

I don't know what that random stuff was about, I thought I cleanly merged your branches.

Like I noted somewhere, those were all compiler warnings I was getting from the RPM build process, which uses a lot more flags.

[fizzyade]

When I got the code compiling on Ubuntu 18.04, the Qt version supplied with the OS doesn't have the QRandomGenerator class, it's too old. I switched out to using std::random to solve the problem, there were a few other changes with regards to threads that I switched to using std::thread as again the QThread implementation on some OS's it too old to support lambdas.

I'm still considering taking a good look at the moc code for 5.7 so that I can make it support compact namespaces, it would be nice to get the code running on Debian 9. I guess I should set up a debian 9 VM.

[fizzyade]

@AaronDMarasco I've pushed a couple of changes to the deployment script, you can now pass a gpg key identifier with the --cert parameter and sign the deb or rpm package.

[fizzyade]

I, of course, managed to mess it up but have pushed a fix. :p

I also added msg_printer blocks to the signing, but the deb_create is wrapped at the deploy.py level and the rpm isn't, so the rpm message saying signing worked fine, but the deb was broken. I've removed the msg_printer that I added to the deb and rpm scripts.

I have a packagecloud.io account now set up, so next up is sorting uploading the binaries to that.

[fizzyade]

@AaronDMarasco Well, this is odd, the signing works on everything apart from Fedora r32

it's hanging on the sign command when called from the script, this is the line it's executing:

rpm --define "_gpg_name hello@nedrysoft.com" --addsign "bin/x86_64/Deploy/rpm/pingnoo-2021.03.23-1.fc32.x86_64.rpm"

if I run it the command directly from the terminal, it signs and exits straight away, but calling the exact same command from the python script it hangs forever. The issue doesn't happen on Fedora 33.

[fizzyade]

I solved it by changing the command to rpmsign and adding the following defines:

if key: execute(f'rpm --define \"_gpg_name {key}\" '\ '--define \"_signature gpg\" '\ '--define \"%_gpg_path /root/.gnupg\" '\ '--define \"%_gpgbin /usr/bin/gpg\" '\ '--addsign \"bin/{build_arch}/Deploy/rpm/{final_name}\"')

[AaronDMarasco]

I solved it by changing the command to rpmsign and adding the following defines

Cool; sorry I don't know anything about signing RPMs.

[AaronDMarasco]

I also added msg_printer blocks to the signing, but the deb_create is wrapped at the deploy.py level and the rpm isn't, so the rpm message saying signing worked fine, but the deb was broken. I've removed the msg_printer that I added to the deb and rpm scripts.

I can try to look into this tomorrow if you'd like. File a bug on my fork if you do.

[fizzyade]

@AaronDMarasco there doesn't appear to be an issue tracker on your fork?

[AaronDMarasco]

doesn't appear to be an issue tracker on your fork?

TIL... OK there is now.