[oe] [PATCH] bluez4_4.95.bb: new recipe for building bluez-4.95
Paul Menzel
paulepanter at users.sourceforge.net
Sun Oct 30 11:42:19 UTC 2011
Dear Vita,
are you reading the list or do I have to add your address to the CC
field?
Am Sonntag, den 30.10.2011, 10:58 +0100 schrieb Preskovsky, Vita:
> Please see my answers bellow.
thank you for your answer.
> -----Original Message-----
> Sent: Tuesday, October 11, 2011 4:32 PM
> Subject: Re: [oe] [PATCH] bluez4_4.95.bb: new recipe for building bluez-4.95
>
> Dear Vita,
>
>
> thank you for your patch.
>
> Am Dienstag, den 11.10.2011, 11:08 +0200 schrieb Vita Preskovsky:
>
> Using
>
> bluez4: Add version 4.95
>
> as the commit summary would be cleaner. Use `git commit --amend` to change that.
>
> Additionally you should elaborate more in the commit message what the patch is doing.
>
> 1. Have you tested it? Is it just an upgrade because of or does version
> 4.91 in the repository have any short comings so that it should be removed?
>
> I tested this recipe, and the reason I added this version is that we want to use this version of Bluez in our release.
I guess you tested it using Ȧngström, so the old recipe can be removed.
Please note that oe-core already has version 4.96.
> > Signed-off-by: Vita Preskovsky <vitap at ti.com>
> > ---
> > recipes/bluez/bluez4_4.95.bb | 30 ++++++++++++++++++++++++++++++
> > 1 files changed, 30 insertions(+), 0 deletions(-) create mode 100644
> > recipes/bluez/bluez4_4.95.bb
> >
> > diff --git a/recipes/bluez/bluez4_4.95.bb
> > b/recipes/bluez/bluez4_4.95.bb new file mode 100644 index
> > 0000000..a682d6a
> > --- /dev/null
> > +++ b/recipes/bluez/bluez4_4.95.bb
> > @@ -0,0 +1,30 @@
> > +require bluez4.inc
> > +SRC_URI = "\
> > + http://www.kernel.org/pub/linux/bluetooth/bluez-${PV}.tar.gz \
>
> 2. As far as I know kernel.org after the compromise presently does not provide that archive. So the recipe will not build unless there is a mirror somewhere. Do you know of a mirror?
>
> There are two possible locations for this package:
> http://www.mirrorservice.org/sites/ftp.kernel.org/pub/linux/bluetooth/bluez-4.95.tar.gz
> http://www.angstrom-distribution.org/unstable/sources/bluez-4.95.tar.gz
> I changed the SRC_URI in my working directory for the first location and it worked fine. So with what location do you prefer the recipe will be released?
I am unsure about the policy myself and I do not think an “OE mirror”
has that particular archive.
> > + file://bluetooth.conf \
> > +"
> > +
> > +SRC_URI[md5sum] = "341294b2849a04a4afff5c96bfbf30b2"
> > +SRC_URI[sha256sum] = "d6ea9de410fc2bcd2620d709c2202893b218e2e6a55c3c0ce6bebd27fa4120f6"
> > +
> > +DEFAULT_PREFERENCE = "-1"
>
> 3. Why?
> > +DEFAULT_PREFERENCE_angstrom = "1"
>
> 4. Have you talked to the Ȧngström maintainers?
>
> These two variables are defined in the previous version of bluez4 recipe: bluez4_4.89.bb. Without these two definitions in my recipe bitbake prefers the old recipe upon mine, which doesn't leave me a choice but to define these variables.
The “correct” way would be to first add that recipe and then afterward
sent a patch to change the preferences which the Ȧngström maintainers
have to acknowledge.
> > +
> > +DEPENDS += "libsndfile1"
> > +
> > +PR = "${INC_PR}.0"
> > +
> > +# Not all distros have a recent enough udev BTUDEV = "
> > +--disable-udevrules"
> > +BTUDEV_angstrom = " --enable-udevrules"
> > +BTUDEV_shr = " --enable-udevrules"
> > +
> > +EXTRA_OECONF += "${BTUDEV}"
> > +do_configure_append(){
> > + echo "#define LIBUDEV_I_KNOW_THE_API_IS_SUBJECT_TO_CHANGE" >>
> > +${S}/config.h }
> > +
> > +FILES_${PN}-dbg += "\
> > + ${base_libdir}/udev/.debug \
> > + ${libdir}/*/.debug \
> > +"
>
> Otherwise this recipe looks good. Is it planned for branch 2011.03-maintenance?
Thanks,
Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20111030/f771c10f/attachment-0002.sig>
More information about the Openembedded-devel
mailing list