[Buildroot] Properly setting up hotplug

[Buildroot] Properly setting up hotplug

[Sagaert Johan]

Hi 
 
cleaning :
 
I don't trust the disclean, it most ends op in a mess.
 
If i do a clean i do :
 
remove the entire root dir in project_build_arm
remove .root  as well
remove all contents from build_arm
remove all stuff in project_build_arm/../autotools-stamps.
 
i am still wondering why they have put dependencies in
project_build_arm/../autotools-stamps. instead of in build_arm
 
removing the entire root seems the only way to make sure packages enabled in
a previous build and disabled now are no longer a lonely ghost in the
rootfs.
 
 
besides this, there are still othter issues, the libssp.so.0 gets build but
not installed in the target root directory.
 
 
 
Johan
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20090417/77507a20/attachment.htm>

[Buildroot] Properly setting up hotplug

[Thiago A. Corrêa]

Hi,

On Fri, Apr 17, 2009 at 5:33 AM, Sagaert Johan <sagaert.johan@skynet.be> wrote:
> Hi
>
> cleaning :
>
> I don't trust the disclean, it most ends op in a mess.

Same here.

> If i do a clean i do :
>
> remove the entire root dir in project_build_arm
> remove .root? as well
> remove all contents from build_arm
> remove all stuff?in project_build_arm/../autotools-stamps.

I actually will do rm -rf build_* binaries project_* most of the time.
If I'm only fixing a package, I might just remove it's folder in the
build_*, but when I want to make sure everything is proper or when
creating an image to download to the device, I will even remove
toolchain_*

I don't like distclean because it will remove the downloaded files,
and clean usually leaves a lot of stuff in the rootfs.

Kind Regards,
   Thiago A. Correa

[Buildroot] Properly setting up hotplug

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

Hi,

 Thiago> I actually will do rm -rf build_* binaries project_* most of
 Thiago> the time.

I normally do rm -rf *build_*.

 Thiago> I don't like distclean because it will remove the downloaded files,

Only if you have it set as BASE_DIR/dl. I expect most people who use
BR on a regular schedule to store their downloads somewhere else.

 Thiago> and clean usually leaves a lot of stuff in the rootfs.

That would be a bug, but yes.

-- 
Bye, Peter Korsgaard

[Buildroot] Properly setting up hotplug

[Lloyd Sargent]

On Apr 17, 2009, at 8:56 AM, Peter Korsgaard wrote:

>>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
>
> Hi,
>
> Thiago> I don't like distclean because it will remove the downloaded  
> files,
>
> Only if you have it set as BASE_DIR/dl. I expect most people who use
> BR on a regular schedule to store their downloads somewhere else.

I would argue then that, conceptually, for BR there should be two  
forms of distclean:

1) to clean up the projects files (i.e. as if you did 'make distclean'  
for directfb)

2) to clean up ALL of BR (i.e. clean up BR for shipment)

The reasoning is that distclean for a package is DIFFERENT than  
distclean for BR - for obvious reasons.

I understand the desire to keep the same underpinnings (since we all  
know about clean and distclean for particular packages) but because BR  
is not about ONE package but many, I think it is conceptually  
stretched, possibly, to the point of failure. Or worse - that saying  
"distclean" means two different things to two different people.

I would argue two types of distclean - package and BR. Now, how to  
implement them I leave up to the experts.

Look forward to my book "The Philosophical Underpinnings of DistClean  
and Why The Guardrails of the Abyss Have Been Removed"

Cheers,

Lloyd

[Buildroot] Properly setting up hotplug

[Peter Korsgaard]

>>>>> "Sagaert" == Sagaert Johan <sagaert.johan@skynet.be> writes:

 Sagaert> Hi
 Sagaert> cleaning :
 
 Sagaert> I don't trust the disclean, it most ends op in a mess.

distclean does a rm -rf dl build_<arch> project_build_<arch>/<project>
binaries/<project>, so that's pretty good.

It currently doesn't get rid for toolchain_build_<arch>, but I'll fix
that now.
 
 Sagaert> i am still wondering why they have put dependencies in
 Sagaert> project_build_arm/../ autotools-stamps. instead of in
 Sagaert> build_arm

Because of the project stuff. There's been discussion about getting
rid of that and simply use the external toolchain stuff if you want to
build seperate rootfs'es for similar hw, and I'm seriously considering
doing so.
 
 Sagaert> besides this, there are still othter issues, the libssp.so.0
 Sagaert> gets build but not installed in the target root directory.

Ohh, details please.

-- 
Bye, Peter Korsgaard

[Buildroot] future of project support

[Hamish Moffatt]

On Fri, Apr 17, 2009 at 03:36:01PM +0200, Peter Korsgaard wrote:
> Because of the project stuff. There's been discussion about getting
> rid of that and simply use the external toolchain stuff if you want to
> build seperate rootfs'es for similar hw, and I'm seriously considering
> doing so.

I'm in favour of some simplification. Here's my usage:

I have a few related projects. I want to build them from the same source
tree. Ideally I can have them all built within one check-out, so I can
quickly make a change and test it in multiple projects (without checking
in, updating the other check out etc).

I don't care if everything is rebuilt for each project.. (except the
toolchain possibly). I think the current mix of build_arch /
project_build_arch is a mess, I'd prefer to have everything in
project_build_arch really.



Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] future of project support

[Peter Korsgaard]

>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:

Hi,

 >> Because of the project stuff. There's been discussion about getting
 >> rid of that and simply use the external toolchain stuff if you want to
 >> build seperate rootfs'es for similar hw, and I'm seriously considering
 >> doing so.

 Hamish> I'm in favour of some simplification. Here's my usage:

 Hamish> I have a few related projects. I want to build them from the
 Hamish> same source tree. Ideally I can have them all built within
 Hamish> one check-out, so I can quickly make a change and test it in
 Hamish> multiple projects (without checking in, updating the other
 Hamish> check out etc).

Have you ever used the out-of-tree build feature? I use it all the
time, and it seems to fit this use case. Simply do make
O=/output/dir/for/project1 and all the build / binaries dirs gets in
/output/dir/for/project1.

 Hamish> I don't care if everything is rebuilt for each project.. (except the
 Hamish> toolchain possibly). I think the current mix of build_arch /
 Hamish> project_build_arch is a mess, I'd prefer to have everything in
 Hamish> project_build_arch really.

Or simply build_arch if we get rid of the project stuff.

-- 
Bye, Peter Korsgaard

[Buildroot] Properly setting up hotplug

[Peter Korsgaard]

>>>>> "Sagaert" == Sagaert Johan <sagaert.johan@skynet.be> writes:

Hi,

 Sagaert> 1) libssp issue

 Sagaert> I started of with a clean build again to do the check:

 Sagaert> I enabled the packages openssh ,openssl

 Sagaert> After building the libssp.so.0,libssp.so.0.0.0 and libssp.so are under
 Sagaert> build_arm/stagingdir/usr/arm-linux-uclibc/lib
 Sagaert> But they are NOT insite the project_build_arm/.../root

 Sagaert> Generating RSA Key...
 Sagaert> /usr/bin/ssh-keygen: can't load library 'libssp.so.0'
 Sagaert> Generating DSA Key...
 Sagaert> THIS CAN TAKE A MINUTE OR TWO DEPENDING ON YOUR PROCESSOR!

 Sagaert> /usr/bin/ssh-keygen: can't load library 'libssp.so.0'

That's not really an issue with openssh as such, but the fact that we
used to compile gcc with --enable-libssp and NOT install the libs in
the target. It should be fixed in r26182 - r26183.

 Sagaert> 2) dbus

 Sagaert> After distclean the build_arm directoory gets cleaned,but
 Sagaert> the autotools-stamps not, As a result dbus get build again
 Sagaert> but never installed again.(this may apply to others too)

Hmm.. distclean removes toolchain_build_arch, build_arch,
project_build_arch and binaries, so this I don't get. Are you talking
about the dbus-clean / dbus-dirclean make targets instead?

 Sagaert> 3) .. /root/var

 Sagaert> I always remove the var directory and replace it with a
 Sagaert> symlink to /tmp/ I then create the required directory
 Sagaert> structure (var lock, etc) in init.d/ S00mktmp Doing so
 Sagaert> results in var been actually on tmpfs, this avoids that my
 Sagaert> flash gets written.

Yes, that's pretty similar to what the generic target does (/var is on
rootfs, but the subdirs cache, lock, log, pcmcia, run, spool, tmp are
all symlinks to /tmp.

 Sagaert> Maybe this is something to consider making this configurable.

 Sagaert> (for the same reason i have put a symplink /etc/resolv.conf
 Sagaert> pointing to /tmp/ resolv.conf )

Same for the generic target.

-- 
Bye, Peter Korsgaard

[Buildroot] Properly setting up hotplug

[Dan Lyke]

So I know I've gotten a Buildroot install that did this automatically
once, but through various incremental steps I've gotten a kernel that
has the hotplug stuff enabled, and if I

echo /bin/mdev > /proc/sys/kernel/hotplug

or just run "mdev -s" manually I get my hot-plugged devices created, but
I'm sure that at some point I had a system where buildroot had created
the appropriate init script for me.

Am I hallucinating, or to get this as part of the compile do I need to
copy my configs across to a fresh buildroot and make again?

And what's the "make" argument for Buildroot that should clean
everything, but not destroy my configs? "make clean" destroys configs,
or at least did last time I typed it...

Dan

[Buildroot] Properly setting up hotplug

[Peter Korsgaard]

>>>>> "Dan" == Dan Lyke <danlyke@flutterby.com> writes:

 Dan> So I know I've gotten a Buildroot install that did this automatically
 Dan> once, but through various incremental steps I've gotten a kernel that
 Dan> has the hotplug stuff enabled, and if I

 Dan> echo /bin/mdev > /proc/sys/kernel/hotplug

 Dan> or just run "mdev -s" manually I get my hot-plugged devices created, but
 Dan> I'm sure that at some point I had a system where buildroot had created
 Dan> the appropriate init script for me.

 Dan> Am I hallucinating, or to get this as part of the compile do I need to
 Dan> copy my configs across to a fresh buildroot and make again?

The target_busybox does this ("use minimal target skeleton" under the
busybox config).

 Dan> And what's the "make" argument for Buildroot that should clean
 Dan> everything, but not destroy my configs? "make clean" destroys configs,
 Dan> or at least did last time I typed it...

make distclean.

-- 
Bye, Peter Korsgaard

[Buildroot] Properly setting up hotplug

[Thomas Petazzoni]

Le Wed, 15 Apr 2009 20:01:47 +0200,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

>  Dan> And what's the "make" argument for Buildroot that should clean
>  Dan> everything, but not destroy my configs? "make clean" destroys
>  Dan> configs, or at least did last time I typed it...
> 
> make distclean.

Which is quite confusing since :

$ make help | grep distclean
  distclean              - delete all non-source files (including .config)

 :-)

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] Properly setting up hotplug

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> make distclean.

 Thomas> Which is quite confusing since :

 Thomas> $ make help | grep distclean
 Thomas>   distclean              - delete all non-source files (including .config)

 Thomas>  :-)

I agree. The clean targets are quite a mess (especially when
considering the project stuff).

I think we should probably just have clean and distclean (and the
individual <target>-clean / -dirclean stuff), where distclean is
clean + rm .config

-- 
Bye, Peter Korsgaard

[Buildroot] Properly setting up hotplug

[Hamish Moffatt]

On Thu, Apr 16, 2009 at 07:59:39PM +0200, Peter Korsgaard wrote:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> 
> Hi,
> 
>  >> make distclean.
> 
>  Thomas> Which is quite confusing since :
> 
>  Thomas> $ make help | grep distclean
>  Thomas>   distclean              - delete all non-source files (including .config)
> 
>  Thomas>  :-)
> 
> I agree. The clean targets are quite a mess (especially when
> considering the project stuff).
> 
> I think we should probably just have clean and distclean (and the
> individual <target>-clean / -dirclean stuff), where distclean is
> clean + rm .config

Are the individual package -clean targets of any value? I never use
them, you are just rebuilding from the same source so what's changed?


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] Properly setting up hotplug

[Peter Korsgaard]

>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:

Hi,

 Hamish> Are the individual package -clean targets of any value? I never use
 Hamish> them, you are just rebuilding from the same source so what's changed?

I do use them while developing - E.G. tweak something in the config
and do make <target>-{,dir}clean; make to test.

-- 
Bye, Peter Korsgaard

[Buildroot] Properly setting up hotplug

[Dan Lyke]

On Fri, 17 Apr 2009 10:42:09 +1000
Hamish Moffatt <hamish@cloud.net.au> wrote:
> Are the individual package -clean targets of any value? I never use
> them, you are just rebuilding from the same source so what's changed?

Although makefiles *should* pick all the dependencies, it's my
experience that they don't. Especially when it comes to changing config
options or random stuff down in the board configs.

The command line

pushd  project_build_arm/at91sam9261ek/linux-2.6.28/ ; make clean ; popd

is an alias on my system...

Dan