[SOLVED] Cannot compile busybox with github actions

Platform Development
#1

Hi Sailors,

I am trying to make a compilation test of this project which can be outdated by my feelings especially because the building platform cites meego. However, I am facing some kind of problems in adapting the RPM spec file to the building action in use.

+ set -m
[163] RPM build errors:
[164] + %setup -n busybox-1.36.1/upstream -q
[165] /var/tmp/rpm-tmp.tr7wUc: line 41: fg: %setup: no such job
[166] error: Bad exit status from /var/tmp/rpm-tmp.tr7wUc (%build)
[167] Bad exit status from /var/tmp/rpm-tmp.tr7wUc (%build)

%build
# TODO: This config should be synced
# with the dynamic config at some point
# currently the features differ quite a bit

Someone can help me or address me to a newer version of this project?

#2

Is it your .spec file or random downloaded one?

#3

Almost it is the .spec file which was present into the project that I forked.

Almost because I did few tries to fix it with the bare minimum effort.

I used the bare minimum bare effort because my sensation is that .spec file is not a good starting point and a comment in it confirmed my suspicious.

Probably there is a similar project like that but updated and not referring to meego.

UPDATE

For sake of completeness, the original .spec file is here:

After all, the beauty of the git is that it keeps tracks of every changes and previous versions.

#4

Likely caused by this commit.

Which is nonsensical for several reasons.

Environment is not carried over from %prep to %build phases.

And I don’t think the %setup and %autosetup macros are defined in %build.

And there is no point in testing during %build whether %prep succeeded because %build will not run if %prep fails.

#5

The build failed before that commit, otherwise that commit did not even existed in first place.

Try again, you will be luckier. Here below the original .spec file.

This is the log of the first build with original .spec file:

Finally, a suggestion: please, try to focus on solving problems not to have a competition with me. Because solving problems is the only positive way to shine brighter.

#6

Except that log shows a completely different error, where %prep and the first steps from %build have already succeeded.

The original .spec file builds fine on OBS, and it’s written for its 'tar_git` repo format.

Does your action’s checkout phase clone submodules as well as the packaging repo? I.e. does it also clone and check out the upstream submodule?

It appears it does not. Try again with the original .spec, and set submodules = true in the checkout phase of the action file.

Sunglasses are readied, in case any bright shining manifests.

#7

Your suggestion works - enough to move forward and discover other sources of failures. Anyway, your contribution has not been overlooked and it goes into these examples:

Obviously, you have been cited as the author of the suggestion. Also here:

The current failure is about the patches which IMHO the action script or the RPM .spec file does not apply and therefore the things are not in the place where it is looking for:

You got your 2nd chance to bright light… :wink:

#8

SOLVED

Finally I managed to solve the problem and here:

You can also download the ZIP that contains the RPM created from the link above.

Only the busybox-static is changed, or better its config is changed:

The most important thing is that everybody now can do the same with busybox and also with others app and RPMs for SailFish OS building on-demand with Github actions:

#9

Availability

Since v0.1.4, the examples and the scripts on this project allow to build a great variety of project from a SFOS UI app like Patch Manager or busybox for SFOS which is the most vital component of the SFOS GNU/Linux subsystem.

Hence, it is the right time to freeze the versioning in order to proved an universal availability for those who rely on this project to build their own RPMs for SFOS.

In order to achieve this the old-stable and the master branches are protected by accidental writings and on the master a specific tag is set. This tag v0.1.4 is also referred by the examples to grant as much as possible to others about the building availability. They can choose to refer to the master HEAD or to update the version in the future editing their action files.

The development process will continue on develop branch that it will be the default branch in such a way everyone land on this page, can access to the last developing version but suggested to use a stable (master) or tagged (v0.1.4) version for maximum availability.