Adds gmergefs. A method of remoting to a target and pushing new

Adds gmergefs.  A method of remoting to a target and pushing new
packages using emerge from the host

[sosa, 2010-04-01 00:34:33]

Adds gmergefs to platform/dev

To use

gmergefs --remote ip_addr package

This takes many of the same arguments as build_packages and build_images.

[Sam Leffler, 2010-04-01 01:16:30]

How is this different from running gmerge on the target?  Does it not
require a dev-server running on the build machine?

I'm guessing you're depending on the test account/cert to get in through ssh?

-Sam

On Thu, Apr 1, 2010 at 12:34 AM,  <sosa@chromium.org> wrote:
> Reviewers: tedbo, rtc,
>
> Message:
> Adds gmergefs to platform/dev
>
> To use
>
> gmergefs --remote ip_addr package
>
> This takes many of the same arguments as build_packages and build_images.
>
> Description:
> Adds gmergefs.  A method of remoting to a target and pushing new
> packages using emerge from the host
>
> Please review this at http://codereview.chromium.org/1515011
>
> Affected files:
>  A src/platform/dev/gmergefs
>  M src/scripts/common.sh
>  M src/scripts/enter_chroot.sh
>  M src/scripts/run_remote_tests.sh
>
>
>

[sosa, 2010-04-01 01:29:55]

It's another approach to doing it that takes advantage of the build
system on the host.  Because this is run on the host, it can use the
existing overlay infrastructure to build the packages from your repo
and build all of its dependencies.  It also has anything you have on
your host like ldconfig which is necessary but not present on the
target for updating the library configuration of the target.

gmerge as it exists now doesn't quite work.  It doesn't do recursive
dependencies and can't build packages that haven't already been
prebuilt on the host.  It also can't run ldconfig so it can't set up
libraries correctly.  Longer term, I think we want to fix gmerge and
this can be used as another option.  But this was a first iteration
fix, and I will be looking into make gmerge awesome later as it may be
what we rely on for dev mode.

-Sosa

On Wed, Mar 31, 2010 at 6:16 PM, Sam Leffler <sleffler@chromium.org> wrote:
> How is this different from running gmerge on the target?  Does it not
> require a dev-server running on the build machine?
>
> I'm guessing you're depending on the test account/cert to get in through ssh?
>
> -Sam
>
> On Thu, Apr 1, 2010 at 12:34 AM,  <sosa@chromium.org> wrote:
>> Reviewers: tedbo, rtc,
>>
>> Message:
>> Adds gmergefs to platform/dev
>>
>> To use
>>
>> gmergefs --remote ip_addr package
>>
>> This takes many of the same arguments as build_packages and build_images.
>>
>> Description:
>> Adds gmergefs.  A method of remoting to a target and pushing new
>> packages using emerge from the host
>>
>> Please review this at http://codereview.chromium.org/1515011
>>
>> Affected files:
>>  A src/platform/dev/gmergefs
>>  M src/scripts/common.sh
>>  M src/scripts/enter_chroot.sh
>>  M src/scripts/run_remote_tests.sh
>>
>>
>>
>

[sosa, 2010-04-01 01:32:32]

To follow-up this approach  has three requirements:

1)  Fuse is installed on development machine
2)  You can ssh to the target system
3)  You set up a root password on target (so you needed to have setup
a password before for chronos)

On Wed, Mar 31, 2010 at 6:29 PM, Chris Sosa <sosa@chromium.org> wrote:
> It's another approach to doing it that takes advantage of the build
> system on the host.  Because this is run on the host, it can use the
> existing overlay infrastructure to build the packages from your repo
> and build all of its dependencies.  It also has anything you have on
> your host like ldconfig which is necessary but not present on the
> target for updating the library configuration of the target.
>
> gmerge as it exists now doesn't quite work.  It doesn't do recursive
> dependencies and can't build packages that haven't already been
> prebuilt on the host.  It also can't run ldconfig so it can't set up
> libraries correctly.  Longer term, I think we want to fix gmerge and
> this can be used as another option.  But this was a first iteration
> fix, and I will be looking into make gmerge awesome later as it may be
> what we rely on for dev mode.
>
> -Sosa
>
> On Wed, Mar 31, 2010 at 6:16 PM, Sam Leffler <sleffler@chromium.org> wrote:
>> How is this different from running gmerge on the target?  Does it not
>> require a dev-server running on the build machine?
>>
>> I'm guessing you're depending on the test account/cert to get in through ssh?
>>
>> -Sam
>>
>> On Thu, Apr 1, 2010 at 12:34 AM,  <sosa@chromium.org> wrote:
>>> Reviewers: tedbo, rtc,
>>>
>>> Message:
>>> Adds gmergefs to platform/dev
>>>
>>> To use
>>>
>>> gmergefs --remote ip_addr package
>>>
>>> This takes many of the same arguments as build_packages and build_images.
>>>
>>> Description:
>>> Adds gmergefs.  A method of remoting to a target and pushing new
>>> packages using emerge from the host
>>>
>>> Please review this at http://codereview.chromium.org/1515011
>>>
>>> Affected files:
>>>  A src/platform/dev/gmergefs
>>>  M src/scripts/common.sh
>>>  M src/scripts/enter_chroot.sh
>>>  M src/scripts/run_remote_tests.sh
>>>
>>>
>>>
>>
>

[sosa, 2010-04-02 18:31:49]

Looks like tedbo is out of town and rtc is busy.  Can you take a look at this CL
adlr along with the other one I'm about to send you?

[adlr, 2010-04-02 19:12:34]

http://codereview.chromium.org/1515011/diff/5001/6001
File src/platform/dev/gmergefs (right):

http://codereview.chromium.org/1515011/diff/5001/6001#newcode72
src/platform/dev/gmergefs:72: [[ $FLAGS_installmask -eq $FLAGS_TRUE ]] &&
INSTALL_MASK="/usr/include/ /usr/man /usr/share/man /usr/share/doc
/usr/share/gtk-doc /usr/share/gtk-2.0 /usr/lib/gtk-2.0/include /usr/share/info
/usr/share/aclocal /usr/lib/gcc /usr/lib/pkgconfig /usr/share/pkgconfig
/usr/share/gettext /usr/share/readline /etc/runlevels /usr/share/openrc /lib/rc
*.a *.la"
80 cols

http://codereview.chromium.org/1515011/diff/5001/6001#newcode75
src/platform/dev/gmergefs:75: [[ $FLAGS_jobs -ne -1 ]]  &&
EMERGE_JOBS="--jobs=$FLAGS_jobs"
ditch extra space before &&

http://codereview.chromium.org/1515011/diff/5001/6001#newcode85
src/platform/dev/gmergefs:85: # Setup sshfs remote mount on target machine
does this comment reference anything?

http://codereview.chromium.org/1515011/diff/5001/6003
File src/scripts/enter_chroot.sh (right):

http://codereview.chromium.org/1515011/diff/5001/6003#newcode147
src/scripts/enter_chroot.sh:147: INNER_MOD_PATH="$(readlink -f
"${FLAGS_chroot}${KERNEL_MODULES_ROOT}")"
80 cols

[adlr, 2010-04-02 19:21:05]

LGTM if you address the comments

On Fri, Apr 2, 2010 at 12:12 PM, <adlr@chromium.org> wrote:

>
> http://codereview.chromium.org/1515011/diff/5001/6001
> File src/platform/dev/gmergefs (right):
>
> http://codereview.chromium.org/1515011/diff/5001/6001#newcode72
> src/platform/dev/gmergefs:72: [[ $FLAGS_installmask -eq $FLAGS_TRUE ]]
> && INSTALL_MASK="/usr/include/ /usr/man /usr/share/man /usr/share/doc
> /usr/share/gtk-doc /usr/share/gtk-2.0 /usr/lib/gtk-2.0/include
> /usr/share/info /usr/share/aclocal /usr/lib/gcc /usr/lib/pkgconfig
> /usr/share/pkgconfig /usr/share/gettext /usr/share/readline
> /etc/runlevels /usr/share/openrc /lib/rc *.a *.la"
> 80 cols
>
> http://codereview.chromium.org/1515011/diff/5001/6001#newcode75
> src/platform/dev/gmergefs:75: [[ $FLAGS_jobs -ne -1 ]]  &&
> EMERGE_JOBS="--jobs=$FLAGS_jobs"
> ditch extra space before &&
>
> http://codereview.chromium.org/1515011/diff/5001/6001#newcode85
> src/platform/dev/gmergefs:85: # Setup sshfs remote mount on target
> machine
> does this comment reference anything?
>
> http://codereview.chromium.org/1515011/diff/5001/6003
> File src/scripts/enter_chroot.sh (right):
>
> http://codereview.chromium.org/1515011/diff/5001/6003#newcode147
> src/scripts/enter_chroot.sh:147: INNER_MOD_PATH="$(readlink -f
> "${FLAGS_chroot}${KERNEL_MODULES_ROOT}")"
> 80 cols
>
>
> http://codereview.chromium.org/1515011
>