On Fri, 2006-08-25 at 18:22 +1000, Jamie Lenehan wrote:

On Fri, Aug 25, 2006 at 09:08:09AM +0100, Richard Purdie wrote:
I changed my mind about a dozen times on this, so seeing what someone
else thinks would be good.

I'll try and take a look at the patches this weekend. I can't promise
but I will try :).

review the patches. The name info.bbclass is perhaps too generic though
- could you call it something like autotools-info.bbclass?

The reason I called it info.bbclass is because it's not actually
related to autotools. What it does is provide information about a
target - endianess, 32/64 bit, which libc it's using, what alias
exists for it in a general sort of way.

The autotools.bbclass then makes use of this to decided which site
files to use.

You can argue that both ways. Ultimately, those files are generally used
by configure which implies autotools but other packages also use them to
provide supplementary info, just to confuse the issue :). I like the
idea of some functions like get_info_endianess_select (although your
example doesn't quite match with get_info_choice_endianess) and it would
be good to abstract direct access to the site files.

I still feel info is too generic as we have 101 different forms of info
around and we need to find a better more descriptive name.
config-info.bclass? site-config.bbclass? Calling it autotools-info
doesn't mean none autotooled packages can't use it btw!

I also made use of the info.bbclass to provide the endiness
information to recipes that were currently manaully looking in the
site file to determine this (since the way they currently work breaks
with the site file.)

Just throwing ideas around, rather than create a function for each
option like endiness, why not have a variable which contains the
endiness set by the class and use base_conditional to get the value you
want? This might make things a little more flexiable?

Cheers,

Richard

On Fri, Aug 25, 2006 at 09:40:56AM +0100, Richard Purdie wrote:

On Fri, 2006-08-25 at 18:22 +1000, Jamie Lenehan wrote:

On Fri, Aug 25, 2006 at 09:08:09AM +0100, Richard Purdie wrote:
I changed my mind about a dozen times on this, so seeing what someone
else thinks would be good.

I'll try and take a look at the patches this weekend. I can't promise
but I will try :).

No hurry. I'd had enough of looking at them was all and so figure I
should either throw out or push it of no one else had any comments on
it ;)

[...]

The autotools.bbclass then makes use of this to decided which site
files to use.

You can argue that both ways. Ultimately, those files are generally used
by configure which implies autotools but other packages also use them to
provide supplementary info, just to confuse the issue :). I like the

Right. I focussed too much on the "call it autotools-info" rather
than the "don't call it info cause that's too generic" bit of your
email. I agree with you now that I think about it that way.

idea of some functions like get_info_endianess_select (although your
example doesn't quite match with get_info_choice_endianess) and it would
be good to abstract direct access to the site files.

Duh. I've been unable to decide on what to call the damn thing and
the two diffs were taken a few minutes apart - and I'd renamed it
(again!) during those few minutes.

I still feel info is too generic as we have 101 different forms of info
around and we need to find a better more descriptive name.
config-info.bclass? site-config.bbclass? Calling it autotools-info
doesn't mean none autotooled packages can't use it btw!

Yep. Agreed. config-info or target-info or something would probably make
more sense.

I also made use of the info.bbclass to provide the endiness
information to recipes that were currently manaully looking in the
site file to determine this (since the way they currently work breaks
with the site file.)

Just throwing ideas around, rather than create a function for each
option like endiness, why not have a variable which contains the
endiness set by the class and use base_conditional to get the value you
want? This might make things a little more flexiable?

I didn't know about base_conditional, but now that I look it - yeah
that looks like it's very close to what I was trying to do and it'll
work fine in this case. And pre-loading into variables is probably a
good idea as well.

Thanks.

--
Jamie Lenehan <lenehan@...>

Sorry, I'm much too busy to seriously comment on that now, but I want to
drop you a note that I'm really liking this idea. Most everything that
reduces redundance is a relief for future maintenance effort.
--
Regards,

Michael 'Mickey' Lauer | FreeLancer | http://www.Vanille-Media.de

http://bugs.openembedded.org/show_bug.cgi?id=1358

Summary: gkdial packages doesn't create required /etc/chatscripts
directory
Product: Openembedded
Version: OpenZaurus 3.5.4.x
Platform: ARM
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: Distributions
AssignedTo: openembedded-devel@...
ReportedBy: uncle.grog@...
QAContact: tinderbox-oe@...


As the summary says, the gkdial package doesn't create the needed
/etc/chatscripts directory to be able to save host information.


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Hi all,
I am trying to build an opie image but busybox fails.
I got this :

| /home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/usr/sbin:

| chroot
| fbset
| rdate
| udhcpd
|
| /home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/usr/share:

| udhcpc
|
| /home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/usr/share/udhcpc:

| default.script
| mv: cannot overwrite directory `/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/bin'


| mv: cannot overwrite directory `/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/sbin'


| mv: cannot overwrite directory `/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/usr'


NOTE: Task failed: /home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/temp/log.do_install.19657

NOTE: package busybox-1.2.1-r1: task do_package: failed
ERROR: TaskFailed event exception, aborting
NOTE: package busybox-1.2.1: failed
ERROR: Build of opie-image failed


Any hint please ?


Amine.

http://bugs.openembedded.org/show_bug.cgi?id=1353





------- Comment #1 from pb@... 2006-08-26 03:32 -------
No, this is not a reasonable solution. Your proposed patch will simply break
bluetooth support for everyone else.

If you want to make bluetooth optional then you would need to:

1. patch gpe-auto-bluetooth.sh to fail silently when gpe-bluetooth is not
installed, rather than producing an error; and

2. move gpe-bluetooth from RDEPENDS to RRECOMMENDS in the gpe-session-scripts
packaging.


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

On 8/26/06, Mohammed Amine SAYA <amine.saya@...> wrote:

Hi all,
I am trying to build an opie image but busybox fails.
I got this :

[...]

|
/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/usr/share/udhcpc:

| default.script
| mv: cannot overwrite directory

Cannot overwrite directory?
Sounds like a permission problem.
Did you build as root once?
Try to manually rm -rf
/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image

regards
Philipp

http://bugs.openembedded.org/show_bug.cgi?id=1353


bugs.openembedded.org@... changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |bugs.openembedded.org@...
| |eggewie.biz




------- Comment #2 from bugs.openembedded.org@... 2006-08-26 05:03 -------
The same is also true for bluetooth stuff in opie and for example the collie.
It is installed by default and consumes precious space on the flash system.
Should I open a new bug report or shall we broaden this bug report to make
bluetooth optional on all images?


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Mohammed Amine SAYA wrote:

Mohammed Amine SAYA wrote:

| mv: cannot overwrite directory
`/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/bin'
| mv: cannot overwrite directory
`/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/sbin'
| mv: cannot overwrite directory
`/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/usr'

Cannot overwrite directory?
Sounds like a permission problem.
Did you build as root once?

No

Try to manually rm -rf
/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image

It worked, I removed it the image directory.
I used to build opie successfully with the old openembedded database
(until monotone 0.25) and bitbake 1.3.X.
I don't know what's happening. I ls -l almost all busybox directories in
$HOME/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1
and everything
seems to belong to me with the right mode.

It turns out that this line inside do_install function in
busybox_1.2.1.bb file is causing the trouble :
mv ${D}${base_bindir} ${D}${base_sbindir} ${D}${prefix} ${D}/busybox/

I replaced "mv" with "cp -a" and it works, does anyone object to that or
have a better fix ?

I have the same problem. I think that the installation routine of
busybox was slightly changed. The bin, sbin and usr directories already
exists in the busybox directory, so the above mv command will fail...

pHilipp Zabel wrote:

On 8/26/06, Mohammed Amine SAYA <amine.saya@...> wrote:

Hi all,
I am trying to build an opie image but busybox fails.
I got this :

[...]

|
/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/usr/share/udhcpc:

| default.script

| mv: cannot overwrite directory `/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/bin'
| mv: cannot overwrite directory `/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/sbin'
| mv: cannot overwrite directory `/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/usr'

| mv: cannot overwrite directory

Hi Philipp,
Thank you for your help.

Cannot overwrite directory?
Sounds like a permission problem.
Did you build as root once?

No

Try to manually rm -rf
/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image

It worked, I removed it the image directory.
I used to build opie successfully with the old openembedded database (until monotone 0.25) and bitbake 1.3.X.
I don't know what's happening. I ls -l almost all busybox directories in $HOME/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1 and everything
seems to belong to me with the right mode.


Still not working.

Amine.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bitbake busybox -c clean ; bitbake busybox
and your problem automagically disappears
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE8EeOMkyGM64RGpERAsqwAJwKdN5WbLM6W2hnHHWbVp1KFvzttgCgkIa8
QwzGLHNjgZforTtpS1Vl2O8=
=7F2d
-----END PGP SIGNATURE-----

Mohammed Amine SAYA wrote:

| mv: cannot overwrite directory `/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/bin'
| mv: cannot overwrite directory `/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/sbin'
| mv: cannot overwrite directory `/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image/busybox/usr'

Hi Philipp,
Thank you for your help.

Cannot overwrite directory?
Sounds like a permission problem.
Did you build as root once?

No

Try to manually rm -rf
/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1/image

It worked, I removed it the image directory.
I used to build opie successfully with the old openembedded database (until monotone 0.25) and bitbake 1.3.X.
I don't know what's happening. I ls -l almost all busybox directories in $HOME/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/arm-linux/busybox-1.2.1-r1 and everything
seems to belong to me with the right mode.

It turns out that this line inside do_install function in busybox_1.2.1.bb file is causing the trouble :
mv ${D}${base_bindir} ${D}${base_sbindir} ${D}${prefix} ${D}/busybox/

I replaced "mv" with "cp -a" and it works, does anyone object to that or have a better fix ?


Amine.

http://bugs.openembedded.org/show_bug.cgi?id=1360

Summary: Build error in Subversion 1.3.2
Product: Openembedded
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Build
AssignedTo: openembedded-devel@...
ReportedBy: yuecelm@...
QAContact: tinderbox-oe@...


I get an error in the stage phase while building version 1.3.2 of Subversion.
An error dump is included in the attachment section. I dont really understand
why the library apr-util cannot be find. This issue was not observed by older
versions.


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.openembedded.org/show_bug.cgi?id=832


yuecelm@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED




------- Comment #10 from yuecelm@... 2006-08-26 07:21 -------
apr uses now an apache mirror, no problem with downloading...


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Koen Kooi wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bitbake busybox -c clean ; bitbake busybox
and your problem automagically disappears

No It does not, I did that like thousand times and I got the same problem again and again.
replacing mv with cp -a fixed it.

Mustafa Yuecel wrote:

I have the same problem. I think that the installation routine of
busybox was slightly changed. The bin, sbin and usr directories already
exists in the busybox directory, so the above mv command will fail..

Yes I think that too.

Did somebody get a problem with sysvinit-2.86 ?
It complains about an existing link :

ln: `/home/users/asaya/Work/OpenEmbedded/OpenEmbedded-Dev1-mnt028/build/tmp/work/at91sam9261-linux/sysvinit-2.86-r28/image/etc/rc2.d/S99stop-bootlogd': File exists



Best regards,

Amine.

http://bugs.openembedded.org/show_bug.cgi?id=1353





------- Comment #3 from hma@... 2006-08-26 07:39 -------
It is good news for SL-C series of Zaurus users if bluetooth is going to be
optional.
* SL-C860, SL-C760, SL-C750, SL-C700
* SL-C3200, SL-C3100, SL-C3000
* SL-C1000
In OpenZaurus machine name, they are c7x0, terrier, borzoi, spitz, akita.
They don't have built-in Bluetooth facility.
In these machines, bluetooth packages should be recommended instead of depended
on.
Especially it is effective for c7x0, as noted by Rolf, flash area for
root partition is small.

SL-6000W has built-in bluetooth facility.
In this machine bluetooth may be depended on.

At a glance, gpe-auto-bluetooth is already non-bluefish-package ready.
Isn't it?
/etc/sysconfig/bluetooth exists for non-bluetooth machines?


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.openembedded.org/show_bug.cgi?id=1353





------- Comment #4 from koen@... 2006-08-26 07:50 -------
*ploink*


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.openembedded.org/show_bug.cgi?id=1354


bugs.openembedded.org@... changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED




------- Comment #1 from bugs.openembedded.org@... 2006-08-26 07:51 -------
It does build again. Reason unknown to me.


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.openembedded.org/show_bug.cgi?id=1361

Summary: Compile error while building cyrus-imapd-2.2.12 with
gcc4
Product: Openembedded
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Build
AssignedTo: openembedded-devel@...
ReportedBy: yuecelm@...
QAContact: tinderbox-oe@...


I get a compile error. An error dump is included in the attachment section.

OE Build Configuration:
BB_VERSION = "1.6.0"
OE_REVISION = "10926eec6b5cb3adcd7df2208e2378bd1fc98cbd"
TARGET_ARCH = "armeb"
TARGET_OS = "linux"
MACHINE = "nslu2"
DISTRO = "openslug"
DISTRO_VERSION = "4.0-beta"
TARGET_FPU = "soft"

gcc4 is rejecting decorations like the following:

struct imapopt_s imapopts[]

To fix this gcc4 warning, I also attach a patch to change it to:

struct imapopt_s * imapopts

The package will be builded without problems. But as long its not tested or
someone approves the changes, I will not commit it to OE.


--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.