Hi,

I am Bill Mills from TI.  I can't use my @ti.com e-mail address on this
forum or github project so I will be using this gmail one at least for now.

Getting hands on with ISAR has been on my TODO list since DebConf in
Montreal.  I finally got around to this last Wednesday (11/15).

I have been using OE since 2008 and Yocto Project since its inception.  I
am a log time Ubuntu user so I consider myself a decently knowledgeable
power user for Debian style distros.

The above is to give you some context.  It is also to show that I have more
experience than many of your potential users.

The good news:

In a fresh Debian Jessie VM I had no problem following your directions and
getting builds for QEMU armhf, i386, and amd64.

A good number of the problem I found and worked around were fixed in the
push to master on Nov 17:  rerepro & python package dependences, misplaced
proc mount, clean up of dev and proc mounts on failure,

The improvements I think you could make for new users:

1) The user documentation should say what host distros are supported.

It is clear from the user doc that it was written for Debian jessie but it
does not say that explicitly.  It also does not say if others could work.

I think you should state which distros you are testing on and warn users
away from any others.
Of course centos, opensuse etc will not work and you should be clear about
this.

Which distros _should_ be test?  IMHO it should be:
Debian: stable, oldstable
Ubuntu: LTS, LTS-1

If that is not possible then documenting the one that does work is even
more important.

<TLDR>
Ubuntu 16.04 does not work, I tried,  I even used the multistrap from
jessie-backports and it still fails with the same error:
W: Failed to fetch
http://ftp.debian.org/debian/dists/jessie/main/binary-armhf/Packages  404
Not Found [IP: 130.89.148.12 80]
</TLDR>

2) The user documentation should guide the user to setup a new VM (or
container) to do the work in.

I think you should guide new users to do the work in a clean VM and say
that containers don't work.  For users that don't have a preferred way to
setup a VM you should pick one and guide them.

<TLDR>
Since you run parts as root and require passwordless sudo, the user should
really be doing this work with a safety net even if they are running on a
supported host distro.

If your day job is ISAR then perhaps you are running native but this won't
be the case for most people trying this out.

I first thought I would try a container.

I tried docker a bit and failed.  (I am not an experienced docker user).

I next tried lxd which I have used a decent bit.  Even with a privileged
container I could not get ISAR to run.  It would fail when trying to mount
/dev into the buildroot.

I did see discussion of docker debian/jessie-slim etc in one of the github
issues.  Is someone running ISAR in docker?  If so I would like to know how
to make this work.

After failing containers I tried a fresh VM.  I tried it two ways and both
worked.

While travelling last weekend I used Virtualbox on Windows to run the
Debian Jessie netinstall CD.  When I got back home I used vagrant with
libvirt provider on Ubuntu. (Vagrant w/ Virtualbox on Windows and Linux
should work also but I did not try these).  Of course spinning up a machine
in a cloud provider should work as well but I did not try.
</TLDR>

3) Provide extra host configuration guidance

I know how to enable jessie-backports but I am not sure everyone will.

Some methods of getting a clean VM leaves the locales unconfigured which
causes a problem with bitbake.  I use:
sudo dpkg-reconfigure locales

and then pick en_US.UTF-8 UTF8 from the text menu.
I think there are better ways also.

4) Provide a build dir delete script or task

Since some of the files in the build dir are owned by root, the normal user
can't delete them.  The user will be tempted to do sudo -rf build but that
is very dangerous if there are stray mounts in the tree.

I know you have added more cleanup of the dev and proc mounts but I worry
that it may not cover every situation.  sudo rm -rf /dev is a rather nasty
thing to do.

I know you are looking to add support for psuedo but that may not be enough
and may take some time to get there.

I think you should put a ./delete-build-dir scipt into the base of the
build dir when you create it.
This script could iterate sudo umount commands, run a user level rm -rf and
then check that what is left is truly expected before doing sudo rm -rf on
it.

Of course if the user is in a VM the damage is contained and a reboot of
the VM should fix things but this would still be good practice IMHO.

-------

Should I create issues for these 4 items?

This is my feedback so far.
I did read over the recipes, classes and main scripts and have a decent
understanding of the basics.

Thanks for your attention.
Bill