All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Tanu Kaskinen <tanuk@iki.fi>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v2 2/5] alsa-ucm-conf: new recipe, version 1.2.1.2
Date: Sat, 1 Feb 2020 11:31:54 +0100	[thread overview]
Message-ID: <CA+chaQc8ak9FNc=JxvVxL-w3z5u1ukPifRBfjUL4+WwO9GWw9Q@mail.gmail.com> (raw)
In-Reply-To: <5259176251b3dcbf2c0600bb343b8484c4bdb53c.camel@iki.fi>

[-- Attachment #1: Type: text/plain, Size: 6602 bytes --]

In LuneOS we have .bbappend in distro layer adding the UCM files for
MACHINEs we support.

It's not nice, but before this recipe we were adding the same in alsa-lib
bbappend, so it's not worse than before for sure.

BSP layer with .bbappend is a bit worse, because including BSP layer
shouldn't change anything for other MACHINEs. For UCM it's on edge, because
if the files are added correctly, then there won't be any change in
behavior for other MACHINEs in practise, but still people won't be happy
from even alsa-ucm-conf being rebuilt just by adding BSP layer to
bblayers.conf. (In theory distro layers shouldn't influence anything when
their supported DISTRO isn't selected as well, but this rule is much less
enforced, because often it doesn't make much sense to include the distro
layer without using that DISTRO - unlike BSP where multiple BSP layers will
be included just to sequentially build the images for various MACHINEs in
the same build directory).

Maybe nobody replied, because there isn't really good way how to handle
this :/.

On Sat, Feb 1, 2020 at 9:21 AM Tanu Kaskinen <tanuk@iki.fi> wrote:

> On Thu, 2020-01-30 at 15:01 +0100, Nicolas Dechesne wrote:
> > hey,
> >
> > On Mon, Jan 6, 2020 at 10:18 AM Tanu Kaskinen <tanuk@iki.fi> wrote:
> > > The UCM configuration files were moved from the alsa-lib repository to
> a
> > > new alsa-ucm-conf repository. The move was accompanied by a license
> > > change from LGPL2.1 to BSD-3-Clause.
> > >
> > > Signed-off-by: Tanu Kaskinen <tanuk@iki.fi>
> > > ---
> > >  meta/conf/distro/include/maintainers.inc      |  1 +
> > >  .../alsa/alsa-lib_1.2.1.2.bb                  |  2 +-
> > >  .../alsa/alsa-ucm-conf_1.2.1.2.bb             | 23
> +++++++++++++++++++
> > >  3 files changed, 25 insertions(+), 1 deletion(-)
> > >  create mode 100644 meta/recipes-multimedia/alsa/
> alsa-ucm-conf_1.2.1.2.bb
> > >
> > > diff --git a/meta/conf/distro/include/maintainers.inc
> b/meta/conf/distro/include/maintainers.inc
> > > index 39eee9475c..c9fb373f52 100644
> > > --- a/meta/conf/distro/include/maintainers.inc
> > > +++ b/meta/conf/distro/include/maintainers.inc
> > > @@ -35,6 +35,7 @@ RECIPE_MAINTAINER_pn-alsa-lib = "Tanu Kaskinen <
> tanuk@iki.fi>"
> > >  RECIPE_MAINTAINER_pn-alsa-plugins = "Tanu Kaskinen <tanuk@iki.fi>"
> > >  RECIPE_MAINTAINER_pn-alsa-state = "Tanu Kaskinen <tanuk@iki.fi>"
> > >  RECIPE_MAINTAINER_pn-alsa-tools = "Tanu Kaskinen <tanuk@iki.fi>"
> > > +RECIPE_MAINTAINER_pn-alsa-ucm-conf = "Tanu Kaskinen <tanuk@iki.fi>"
> > >  RECIPE_MAINTAINER_pn-alsa-utils = "Tanu Kaskinen <tanuk@iki.fi>"
> > >  RECIPE_MAINTAINER_pn-alsa-utils-scripts = "Tanu Kaskinen <
> tanuk@iki.fi>"
> > >  RECIPE_MAINTAINER_pn-apmd = "Anuj Mittal <anuj.mittal@intel.com>"
> > > diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
> b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
> > > index 9565ad1b20..7bc78b8523 100644
> > > --- a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
> > > +++ b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
> > > @@ -33,7 +33,7 @@ FILES_alsa-server = "${bindir}/*"
> > >  FILES_alsa-conf = "${datadir}/alsa/"
> > >  FILES_libatopology = "${libdir}/libatopology.so.*"
> > >
> > > -RDEPENDS_${PN}_class-target = "alsa-conf"
> > > +RDEPENDS_${PN}_class-target = "alsa-conf alsa-ucm-conf"
> > >
> > >  # upgrade path
> > >  RPROVIDES_${PN} = "libasound"
> > > diff --git a/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
> b/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
> > > new file mode 100644
> > > index 0000000000..469d1f7a95
> > > --- /dev/null
> > > +++ b/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
> > > @@ -0,0 +1,23 @@
> > > +SUMMARY = "ALSA Use Case Manager configuration"
> > > +HOMEPAGE = "https://alsa-project.org"
> > > +BUGTRACKER = "https://alsa-project.org/wiki/Bug_Tracking"
> > > +LICENSE = "BSD-3-Clause"
> > > +LIC_FILES_CHKSUM =
> "file://LICENSE;md5=20d74d74db9741697903372ad001d3b4"
> > > +
> > > +# The tarball doesn't have any toplevel directory. The subdir option
> tells
> > > +# Bitbake to unpack the archive to the correct place.
> > > +SRC_URI = "
> https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2;subdir=${BP}"
> > > +SRC_URI[md5sum] = "b7fa43cfd79df978184a6333766d2a50"
> > > +SRC_URI[sha256sum] =
> "ea8a86875f4cf430d49a662a04a6d6c606c5c9d67e54cb944c4d77b24554062f"
> > > +
> > > +inherit allarch
> >
> > it's a bit late into the game.. but I have some questions about this
> > patch. now that the alsa-ucm-conf are allarch, how do we expect a BSP
> > layer to provide its own UCM config files? if i add a .bbappend file,
> > I can't change PACKAGE_ARCH to be 'machine' specific. If i create a
> > new recipe for my custom UCM files, then it's not obvious when I
> > should install them, since we need them only if alsa-ucm-conf is
> > installed in the first place..
> >
> > I was thinking about adding an empty alsa-ucm-machine-conf recipe that
> > BSP could append,  like gpsd, e.g.:
> >
> http://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-navigation/gpsd/gpsd-machine-conf_1.0.bb
> >
> > Is that a good idea?
>
> I was hoping someone else would answer this, since I have no experience
> with BSPs or .bbappend files... Since I don't know how this *should* be
> done, I'm not against creating alsa-ucm-machine-conf. However, my
> intuition would be that the BSP installs its configuration as a
> separate recipe whenever the BSP is used. I don't see the need to have
> conditions such as "install only if alsa-ucm-conf is installed". Is it
> just to save disk space? alsa-ucm-conf anyway installs a bunch of files
> that aren't relevant to most machines, so if you're worried about UCM
> disk consumption, the alsa-ucm-conf recipe would need work to somehow
> install only those files that are needed by the current machine.
>
> Another approach that would make sense to me (even more than creating a
> separate recipe) is to submit your UCM config to ALSA upstream. While
> waiting for the change to get accepted to upstream and then later
> incorporated in the main alsa-ucm-conf recipe, you could use .bbappend
> to add the configuration to the alsa-ucm-conf recipe as a patch.
>
> --
> Tanu
>
> https://www.patreon.com/tanuk
> https://liberapay.com/tanuk
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 9954 bytes --]

  reply	other threads:[~2020-02-01 10:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-06  9:18 [PATCH v2 0/5] alsa recipe updates Tanu Kaskinen
2020-01-06  9:18 ` [PATCH v2 1/5] alsa-lib: 1.1.9 -> 1.2.1.2 Tanu Kaskinen
2020-01-06  9:18 ` [PATCH v2 2/5] alsa-ucm-conf: new recipe, version 1.2.1.2 Tanu Kaskinen
2020-01-30 14:01   ` Nicolas Dechesne
2020-02-01  8:15     ` Tanu Kaskinen
2020-02-01 10:31       ` Martin Jansa [this message]
2020-01-06  9:18 ` [PATCH v2 3/5] alsa-topology-conf: new recipe, version 1.2.1 Tanu Kaskinen
2020-01-06  9:18 ` [PATCH v2 4/5] alsa-utils: 1.1.9 -> 1.2.1 Tanu Kaskinen
2020-01-06  9:18 ` [PATCH v2 5/5] alsa-plugins: " Tanu Kaskinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+chaQc8ak9FNc=JxvVxL-w3z5u1ukPifRBfjUL4+WwO9GWw9Q@mail.gmail.com' \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=tanuk@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.