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