no-preinstall: Ready to merge

[Joel Sherrill]

On Mon, Jan 22, 2018 at 5:59 PM, Chris Johns <chrisj at rtems.org> wrote:

> On 23/01/2018 10:50, Joel Sherrill wrote:
> > On Mon, Jan 22, 2018 at 4:35 PM, Chris Johns <chrisj at rtems.org
> > <mailto:chrisj at rtems.org>> wrote:
> >
> >     On 23/01/2018 01:49, Sebastian Huber wrote:
> >     > Hello,
> >     >
> >     > I installed all BSPs of the master and then all BSPs of the
> no-preinstall
> >     > branch.  The difference in installed BSP files is this:
> >     >
> >     > https://ftp.rtems.org/pub/rtems/people/sebh/tmp/headers-diff.txt
> >     <https://ftp.rtems.org/pub/rtems/people/sebh/tmp/headers-diff.txt>
> >     >
> >     > There are no removals.  In the no-preinstall installation, there
> are more header
> >     > files present (this is expected).  If someone has a problem with
> this, then we
> >     > can fine tune this later.  For the preinstall removal this is not
> a blocking point.
> >     >
> >     > The squashed commit is at the top of the no-preinstall branch:
> >     >
> >     > https://git.rtems.org/sebh/rtems.git/log/?h=no-preinstall
> >     <https://git.rtems.org/sebh/rtems.git/log/?h=no-preinstall>
> >     >
> >
> >     I OK with this change being pushed to master.
> >
> >     It would be great if someone who experienced the original problem of
> the
> >     'install' command failing on Linux during the preinstall phase could
> please run
> >     a test build with a large number of jobs to see if the problem has
> been
> >     resolved.
> >
> >
> > I think that was a not so subtle jab at me.
>
> Not really, it was to anyone effected and willing to help test. I seem to
> remember other reports of this happening.
>

Thanks Chris for the help fetching this. I have started a build of all BSPs
on the no-preinstall branch on rtbf64c. I could pretty reliably get failures
on this machine with preinstall and make -j.

I will report in the morning.


>
> > Do you want me to test before or after Sebastian pushes the branch.
>
> I do not mind. This is the original reason for the change and so it would
> be
> nice to be able to close any related tickets. I cannot do this because I
> have
> not seen the problem.
>
> >
> > I am ok pushing it and cleaning up problems as we get more users.
> >
>
> Sure.
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180122/cf1464c4/attachment-0002.html>