| Newsgroups |
gmane.linux.lfs.automated |
| Message-ID |
<CABJoABZOChxOi6zti5PJXPYx==uKf3ne9RTMYsMSaBD02vhUkA@mail.gmail.com> |
On Thu, Oct 6, 2022 at 6:48 AM Marcin Dulak <[email protected]> wrote:
>
>
> On Sat, Oct 1, 2022 at 2:10 AM Marcin Dulak <[email protected]>
> wrote:
>
>>
>> On Fri, Sep 30, 2022 at 8:46 AM Pierre Labastie <
>> [email protected]> wrote:
>>
>>> On Thu, 2022-09-29 at 22:25 +0000, md wrote:
>>> > Hi,
>>> >
>>> > Please let me know what do you think about a feasibility of
>>> decomposing the
>>> > mk_CHROOT target
>>> > into "_before_gcc", "_gcc", and "_after_gcc" targets, so that they
>>> could be
>>> > executed separately, if desired.
>>> >
>>> > I'm experimenting with jhalfs https://github.com/marcindulak/jhalfs-ci
>>> ,
>>> > but getting limited by the github actions runners limit of 6 hours per
>>> job
>>> >
>>> https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits
>>> > .
>>> >
>>> > 6 hours, even after properly (see
>>> >
>>> https://lists.linuxfromscratch.org/sympa/arc/alfs-discuss/2022-09/msg00008.html
>>> > )
>>> > setting make to run two jobs in paralell may be insufficient to perform
>>> > chapter8
>>> >
>>> https://www.linuxfromscratch.org/lfs/view/systemd/chapter08/chapter08.html
>>> .
>>> > A github action runner has 2 cores
>>> >
>>> https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources
>>> > .
>>> >
>>> > Do you think a change like that would be feasible in jhalfs?
>>> > If yes, any recommendations how roughly an implementation would
>>> proceed,
>>> > which parts of the code would need to be modified?
>>>
>>> First suggestion: you can stop make after any package by using "make
>>> BREAKPOINT=<package target>", for example "make BREAKPOINT=823-shadow".
>>> This
>>> exists and is by far the easiest.
>>>
>>
>> I'm going first with the existing method, but a BREAKPOINT results in
>> non-zero exit status,
>> which is not useful when running in an automated way, where I would like
>> to rely on exit status.
>>
>> ```
>> make BREAKPOINT=823-shadow
>> ...
>>
>> --------------------------------------------------------------------------------
>> Building target 823-shadow
>> [++++++++++++++++++++++++++| ] 0 min. 26
>> sec
>> Target 823-shadow OK
>>
>> --------------------------------------------------------------------------------
>> The build has been stopped at 823-shadow as requested
>> make: *** [Makefile:1029: 823-shadow] Error 1
>> make: *** [Makefile:113: mk_CHROOT] Error 2
>> ```
>>
>> The common/makefile-functions file, housekeeping function defines this
>> "The build has been stopped" behavior
>> by returning false. Is there a general solution for this situation, as
>> changing false -> true
>> does not stop the make at 823-shadow, and instead continues to later
>> targets.
>> ```
>> make BREAKPOINT=823-shadow
>> ...
>> mk_CHROOT
>> You are going to CHROOT into /vagrant/jhalfs/mnt/build_dir
>> a password may be required
>>
>> --------------------------------------------------------------------------------
>> Building target 823-shadow
>> [++++++++++++++++++++++++++++++++++++++++++++++++ ] 0 min. 47
>> sec
>> Target 823-shadow OK
>>
>> --------------------------------------------------------------------------------
>> The build has been stopped at 823-shadow as requested
>>
>> --------------------------------------------------------------------------------
>> Building target 824-gcc
>> [++++ ]
>> ```
>>
>> I wonder whether it is feasible to create some kind of wrapper over
>> the housekeeping function by parsing the output,
>> so the function stops the build as requested and does not error out, and
>> errors when it should.
>>
>
> ack'ing for the specific string appearing in the output of make when a
> target builds sucessfully may work.
> The ansi2txt is to remove color formatting, so ack can find the phrase.
> ```
> make BREAKPOINT=823-shadow | ansi2txt | ack --passthru "stopped at
> 823-shadow as requested"
>
in order show the last written log, the command may be extended to
make BREAKPOINT=823-shadow | ansi2txt | ack --passthru "stopped at
823-shadow as requested" || (set -x && cat logs/$(ls -1tr logs | tail -1)
&& exit 1)
> ```
>
>>
>> I would like to rely on the jhalfs trunk, and ideally not use any local
>> modifications when building the project unattended.
>> Would a modification involving the second suggestion be accepted into
>> jhalfs?
>>
>>
>>> Second suggestion: you could directly tweak $BUILD_DIR/jhalfs/Makefile
>>> (with sed
>>> or another stream editor). You'd need to break the long line starting
>>> with
>>> "mk_CHROOT" into three (Note the line containing SHELL is useless for
>>> recent
>>> versions of lfs).
>>> Third suggestion: change the Makefile creation by adding to the case
>>> commands,
>>> at line 95, 108, 124, 189 of LFS/master.sh, and also around line 439.
>>>
>>> >
>>> > I prefer to keep all tests run, but in case 824-gcc alone does not fit
>>> into 6
>>> > hours,
>>> > what would it take to implement a selective test-skip for it?
>>>
>>> Comment out "make -k check" in the script... something like sed '/make -k
>>> check/s/^/#/' (and maybe same for a few other lines)
>>>
>>> Pierre
>>> --
>>> http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
>>> Unsubscribe: See the above information page
>>
>>
--
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page