[elbe-devel] Question: Extracting build chroot environment

[Manuel Traut]

Hi,
  
> > > is there a convenient way to extract the target build chroot
> > > environment from the virtual machine?
> > 
> > if you don't use a mode like tighten or diet and no finetuning,
> > the ./target and ./chroot directory should be the same.
> > 
> > If you use
> > 
> > ...</console>
> > <package>
> > 	<tar>
> > 		<name>rfs.tar.gz</name>
> > 	</tar>
> > </package>
> > <finetuning>...
> > 
> > in your XML, a tarball from the ./target directory will be created
> > (and can be downloaded via project files).
> 
> I use a pkg-list within the "buildimage" tag to install development
> packages.
> 
> So your proposal is to have two XML files, one for the development
> chroot and one for the image. That doubles the time to create both of
> them.

hmm, no that's stupid.

> Currently it takes me about 36 minutes to create just the arm target
> image with the use of apt-cacher-ng* on my physical machine. From what
> I read, you can only build one image at a time per virtual machine and
> can only run one virtual machine per user. That makes concurrency
> rather difficult. Is there any way to speed this process up?

For small changes, you can use 

% elbe initvm submit --keep-files
% elbe control list_projects
% elbe control set_xml
% elbe control build

But removed packages from the pkg-list are not tracked e.g.
For releases we recommend a full build.

> My idea was to create a flashable sdcard image and a development chroot
> environment with the same base system and package versions at the same
> time. So I suppose there is no plan to generate a buildimage-chroot-
> tarball next to the sdcard image within the "elbe initvm *" process?

We should think about a method for chroot extraction. I think it's
useful for some people.

I would prefer an 'elbe control extract_chroot' command that creates
the tarball and makes it available to get_files. The initvm command
should not be overloaded, it is designed to have only basic features
for 'beginners'.
 
> > You can also use 'scp target.tgz user at 10.0.0.2:~/' to copy files from
> > the initvm to your physical PC.
> 
> Yes that is another possibility, but not much better than the ones I
> mentioned. It depends on the host ssh-server, which in my case doesn't
> allow pw login and I don't want to start deploying keys into the
> initvm.

..this is why we created the file transfer via SOAP.. (but scp is faster)
 
> *About the apt-cacher-ng: I use it via the "primary_proxy" setting when
> creating the initvm and target image and have to use the ip address of
> my physical ethernet port, because neither 10.0.2.2 nor 127.0.0.1 works
> in every situation. /etc/hosts on my physical machine seems to be
> ignored too and LOCALMACHINE cannot be set within the primary_proxy
> tag.
> Is there a way to have the XML independent from the mood of the dhcp
> sever and mostly independent for the configuration of the physical
> machine?
> (The DNS server of the network where I work on this project does not
> resolve my hostname)

I think using LOCALMACHINE as primary_proxy is what we want have to work.

Patches for both features are welcome!

Regards,

  Manuel