* [Buildroot] Properly setting up hotplug
@ 2009-04-17 8:33 Sagaert Johan
2009-04-17 8:52 ` Thiago A. Corrêa
2009-04-17 13:36 ` Peter Korsgaard
0 siblings, 2 replies; 15+ messages in thread
From: Sagaert Johan @ 2009-04-17 8:33 UTC (permalink / raw)
To: buildroot
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>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
2009-04-17 8:33 [Buildroot] Properly setting up hotplug Sagaert Johan
@ 2009-04-17 8:52 ` Thiago A. Corrêa
2009-04-17 13:56 ` Peter Korsgaard
2009-04-17 13:36 ` Peter Korsgaard
1 sibling, 1 reply; 15+ messages in thread
From: Thiago A. Corrêa @ 2009-04-17 8:52 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
2009-04-17 8:33 [Buildroot] Properly setting up hotplug Sagaert Johan
2009-04-17 8:52 ` Thiago A. Corrêa
@ 2009-04-17 13:36 ` Peter Korsgaard
2009-04-20 0:32 ` [Buildroot] future of project support Hamish Moffatt
1 sibling, 1 reply; 15+ messages in thread
From: Peter Korsgaard @ 2009-04-17 13:36 UTC (permalink / raw)
To: buildroot
>>>>> "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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
2009-04-17 8:52 ` Thiago A. Corrêa
@ 2009-04-17 13:56 ` Peter Korsgaard
2009-04-17 14:19 ` Lloyd Sargent
0 siblings, 1 reply; 15+ messages in thread
From: Peter Korsgaard @ 2009-04-17 13:56 UTC (permalink / raw)
To: buildroot
>>>>> "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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
2009-04-17 13:56 ` Peter Korsgaard
@ 2009-04-17 14:19 ` Lloyd Sargent
0 siblings, 0 replies; 15+ messages in thread
From: Lloyd Sargent @ 2009-04-17 14:19 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] future of project support
2009-04-17 13:36 ` Peter Korsgaard
@ 2009-04-20 0:32 ` Hamish Moffatt
2009-04-21 6:11 ` Peter Korsgaard
0 siblings, 1 reply; 15+ messages in thread
From: Hamish Moffatt @ 2009-04-20 0:32 UTC (permalink / raw)
To: buildroot
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>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] future of project support
2009-04-20 0:32 ` [Buildroot] future of project support Hamish Moffatt
@ 2009-04-21 6:11 ` Peter Korsgaard
0 siblings, 0 replies; 15+ messages in thread
From: Peter Korsgaard @ 2009-04-21 6:11 UTC (permalink / raw)
To: buildroot
>>>>> "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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
[not found] <E8FBAEC0D1A8452EA1A58E35916B04E6@apexjs>
@ 2009-04-22 8:52 ` Peter Korsgaard
0 siblings, 0 replies; 15+ messages in thread
From: Peter Korsgaard @ 2009-04-22 8:52 UTC (permalink / raw)
To: buildroot
>>>>> "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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
2009-04-17 0:42 ` Hamish Moffatt
2009-04-17 5:20 ` Peter Korsgaard
@ 2009-04-17 14:19 ` Dan Lyke
1 sibling, 0 replies; 15+ messages in thread
From: Dan Lyke @ 2009-04-17 14:19 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
2009-04-17 0:42 ` Hamish Moffatt
@ 2009-04-17 5:20 ` Peter Korsgaard
2009-04-17 14:19 ` Dan Lyke
1 sibling, 0 replies; 15+ messages in thread
From: Peter Korsgaard @ 2009-04-17 5:20 UTC (permalink / raw)
To: buildroot
>>>>> "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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
2009-04-16 17:59 ` Peter Korsgaard
@ 2009-04-17 0:42 ` Hamish Moffatt
2009-04-17 5:20 ` Peter Korsgaard
2009-04-17 14:19 ` Dan Lyke
0 siblings, 2 replies; 15+ messages in thread
From: Hamish Moffatt @ 2009-04-17 0:42 UTC (permalink / raw)
To: buildroot
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>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
2009-04-16 7:10 ` Thomas Petazzoni
@ 2009-04-16 17:59 ` Peter Korsgaard
2009-04-17 0:42 ` Hamish Moffatt
0 siblings, 1 reply; 15+ messages in thread
From: Peter Korsgaard @ 2009-04-16 17:59 UTC (permalink / raw)
To: buildroot
>>>>> "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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
2009-04-15 18:01 ` Peter Korsgaard
@ 2009-04-16 7:10 ` Thomas Petazzoni
2009-04-16 17:59 ` Peter Korsgaard
0 siblings, 1 reply; 15+ messages in thread
From: Thomas Petazzoni @ 2009-04-16 7:10 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
2009-04-14 17:33 Dan Lyke
@ 2009-04-15 18:01 ` Peter Korsgaard
2009-04-16 7:10 ` Thomas Petazzoni
0 siblings, 1 reply; 15+ messages in thread
From: Peter Korsgaard @ 2009-04-15 18:01 UTC (permalink / raw)
To: buildroot
>>>>> "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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] Properly setting up hotplug
@ 2009-04-14 17:33 Dan Lyke
2009-04-15 18:01 ` Peter Korsgaard
0 siblings, 1 reply; 15+ messages in thread
From: Dan Lyke @ 2009-04-14 17:33 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-04-22 8:52 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-17 8:33 [Buildroot] Properly setting up hotplug Sagaert Johan
2009-04-17 8:52 ` Thiago A. Corrêa
2009-04-17 13:56 ` Peter Korsgaard
2009-04-17 14:19 ` Lloyd Sargent
2009-04-17 13:36 ` Peter Korsgaard
2009-04-20 0:32 ` [Buildroot] future of project support Hamish Moffatt
2009-04-21 6:11 ` Peter Korsgaard
[not found] <E8FBAEC0D1A8452EA1A58E35916B04E6@apexjs>
2009-04-22 8:52 ` [Buildroot] Properly setting up hotplug Peter Korsgaard
-- strict thread matches above, loose matches on Subject: below --
2009-04-14 17:33 Dan Lyke
2009-04-15 18:01 ` Peter Korsgaard
2009-04-16 7:10 ` Thomas Petazzoni
2009-04-16 17:59 ` Peter Korsgaard
2009-04-17 0:42 ` Hamish Moffatt
2009-04-17 5:20 ` Peter Korsgaard
2009-04-17 14:19 ` Dan Lyke
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.