RPM build fails

[mbert]

So far the RPM installation has worked flawlessly. But maybe there's a regression after the recent changes? In that case you will probably want to know ;)

Definitely. I've already found problem - I've missed copying GlobalDefaults.plist into /Library/Preferences. This file where global GNUstep preferences stored (backend name, theme name, fonts etc.). You may try to build your RPMs. :)

Originally posted by @trunkmaster in #491

It looks like there's still something wrong with the copying of the GlobalDefaults.plist file:

Making install for app ProjectCenter...
 Installing bundle directory...
+ cd ..
+ cp -f /root/rpmbuild/BUILD/nextspace-gnustep-1.31.1_0.32.0-build/BUILDROOT/Library/Themes/NextSpace.theme/Resources/ThemeImages/common_Tile.tiff /root/rpmbuild/BUILD/nextspace-gnustep-1.31.1_0.32.0-build/BUILDROOT/Library/Images
+ cp /root/rpmbuild/SOURCES/GlobalDefaults.plist /root/rpmbuild/BUILD/nextspace-gnustep-1.31.1_0.32.0-build/BUILDROOT/Library/Preferences
cp: cannot stat '/root/rpmbuild/SOURCES/GlobalDefaults.plist': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.p5DnpV (%install)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.p5DnpV (%install)
================================================================================
 Building of NEXTSPACE GNUstep RPM FAILED!
================================================================================
Aborting...

Regarding RPM builds in general - it's really your choice how you want to deal with these build / infrastructure issues (and I won't argue any further after this). I generally prefer to treat all build, test and infrastructure issues as top priority as they can lead to ugly combinations of issues that are then getting increasingly difficult to disentangle. Also fixing them while they are fresh is usually "cheapest".

I am a bit old-school and rather unfamiliar with github's CI functionality. If it's not too tedious, setting up a CI build for something based on the docker-based build scripts I attached in #491 could probably be something worth to consider in order to catch regressions quickly and automatically.

[trunkmaster]

So far the RPM installation has worked flawlessly. But maybe there's a regression after the recent changes? In that case you will probably want to know ;)
Definitely. I've already found problem - I've missed copying GlobalDefaults.plist into /Library/Preferences. This file where global GNUstep preferences stored (backend name, theme name, fonts etc.). You may try to build your RPMs. :)

Originally posted by @trunkmaster in #491

It looks like there's still something wrong with the copying of the GlobalDefaults.plist file:

Making install for app ProjectCenter...
 Installing bundle directory...
+ cd ..
+ cp -f /root/rpmbuild/BUILD/nextspace-gnustep-1.31.1_0.32.0-build/BUILDROOT/Library/Themes/NextSpace.theme/Resources/ThemeImages/common_Tile.tiff /root/rpmbuild/BUILD/nextspace-gnustep-1.31.1_0.32.0-build/BUILDROOT/Library/Images
+ cp /root/rpmbuild/SOURCES/GlobalDefaults.plist /root/rpmbuild/BUILD/nextspace-gnustep-1.31.1_0.32.0-build/BUILDROOT/Library/Preferences
cp: cannot stat '/root/rpmbuild/SOURCES/GlobalDefaults.plist': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.p5DnpV (%install)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.p5DnpV (%install)
================================================================================
 Building of NEXTSPACE GNUstep RPM FAILED!
================================================================================
Aborting...

Fixed.

Regarding RPM builds in general - it's really your choice how you want to deal with these build / infrastructure issues (and I won't argue any further after this). I generally prefer to treat all build, test and infrastructure issues as top priority as they can lead to ugly combinations of issues that are then getting increasingly difficult to disentangle. Also fixing them while they are fresh is usually "cheapest".

Not quite. It's not the "cheapest" in term of focusing on issue being fixed. Instead of focusing on real issue I need to switch to task that not related to problem I need to fix. Switching between tasks is not "cheap" way to fix issues with code - it's time consuming and boring. The routine development process is debug, code and run make; make install no package building is involved.

OTOH if you are interested in correct RPMs build all the time I'll be glad to see your PR regarding fixes in RPM spec files (that's where most RPM build issues resides). There's no need to have knowledge in C, Objective-C just format of SPEC files and how rpmbuild works.

I am a bit old-school and rather unfamiliar with github's CI functionality. If it's not too tedious, setting up a CI build for something based on the docker-based build scripts I attached in #491 could probably be something worth to consider in order to catch regressions quickly and automatically.

I've GitHub CI (Actions) are quite good for test build purposes. It's exactly how you've described this: docker-based builds. You can look into .github/workflows directory - this is where Actions configured. You could find fedora_rpm.yml that exists but not included in automated build. This is the script for this build - no other scripts needed.

[mbert]

OTOH if you are interested in correct RPMs build all the time I'll be glad to see your PR regarding fixes in RPM spec files (that's where most RPM build issues resides). There's no need to have knowledge in C, Objective-C just format of SPEC files and how rpmbuild works.

Yes, I will have a look next time something crosses my way. I would have done so this week already, but on Tuesdays I usually come home quite late, so that there wasn't really a chance.

I've GitHub CI (Actions) are quite good for test build purposes. It's exactly how you've described this: docker-based builds. You can look into .github/workflows directory - this is where Actions configured. You could find fedora_rpm.yml that exists but not included in automated build. This is the script for this build - no other scripts needed.

That file looks OK to me. But why did it not detect that issue? Or was it just a race condition - the change submitted and the job not yet run? With that particular issue in mind I wouldn't expect a difference between fc41 and fc43 (the other one for which I sent that PR some weeks ago was different, of course).

[trunkmaster]

OTOH if you are interested in correct RPMs build all the time I'll be glad to see your PR regarding fixes in RPM spec files (that's where most RPM build issues resides). There's no need to have knowledge in C, Objective-C just format of SPEC files and how rpmbuild works.

Yes, I will have a look next time something crosses my way. I would have done so this week already, but on Tuesdays I usually come home quite late, so that there wasn't really a chance.

OK

I've GitHub CI (Actions) are quite good for test build purposes. It's exactly how you've described this: docker-based builds. You can look into .github/workflows directory - this is where Actions configured. You could find fedora_rpm.yml that exists but not included in automated build. This is the script for this build - no other scripts needed.

That file looks OK to me. But why did it not detect that issue? Or was it just a race condition - the change submitted and the job not yet run? With that particular issue in mind I wouldn't expect a difference between fc41 and fc43 (the other one for which I sent that PR some weeks ago was different, of course).

I've already wrote several times - RPM packages build is out of my interest until I decide to prepare release. That's why this workflow doesn't have triggered events configured - I run it manually to check if RPMs builds successfully.