All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michel D'HOOGE <michel.dhooge@free.fr>
To: Yocto list discussion <yocto@yoctoproject.org>
Subject: Re: Using debian packages management
Date: Tue, 18 Oct 2016 14:41:12 +0200 (CEST)	[thread overview]
Message-ID: <1132601620.150136748.1476794472685.JavaMail.root@spooler3-g27.priv.proxad.net> (raw)
In-Reply-To: <CAHiDW_F+xxV35z+MMVHwb2Qvp_4+w69a41d9dtEgBT2atE-Psw@mail.gmail.com>

Thanks Jussi, it solved my issue (more explanation below).


> From: "Jussi Kukkonen" <jussi.kukkonen@intel.com>

> I suspect this is related to meta-oe taking over some X
> initialization when you add it to bblayers -- this maybe exposes a
> bug in the deb packaging implementation. In any case I can say that
> a deb-based core-image-sato builds fine without meta-oe.

You were right...
With the bitbake-layers utility, I checked the "appends" but not
the "overlayed" (BTW, -overlaid- would be better!?). And meta-oe
provides a version 2.0 of xserver-nodm-init, which triggers some
problems with debian.


> Note that you may have to wipe TMPDIR after bblayers changes if
> you're testing this.

I didn't have to. I simply set PREFERRED_VERSION_xserver-nodm-init
to "1.0" and I got my image!

But this raises another comment: I added the whole meta-oe layer
for a single recipe (ttf-dejavu). And I inherited unwanted side
effects.

So what is the best practice?
- to copy/paste the recipe into a dedicated layer?
- to modify the conf/layer.conf of meta-oe to include a single folder?



> I have a bug on improving the X initialization mess in oe-core vs
> meta-oe ( https://bugzilla.yoctoproject.org/show_bug.cgi?id=5546 )
> but please file one on the debian packaging issue if it does not
> exist yet.

I just read your bug report… and this problem is quite old.
Before it gets corrected in 2.3, it could be helpful to put a note
in the different Yocto manuals, to draw attention of newcomers to
this rather frequent problem.



@Khem Raj: I realized my answer was maybe a bit harsh and I want
to apologize.  This was just an amused comment that every time I
try something described in the manuals, this fails miserably. And
every time, I have the feeling that my config is close to the
default one. But the goal of Yocto is highly ambitious and it
implies knowledge in many Linux fields!


Michel


      reply	other threads:[~2016-10-18 12:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <290444271.145314951.1476711189434.JavaMail.root@spooler3-g27.priv.proxad.net>
2016-10-17 14:11 ` Using debian packages management Michel D'HOOGE
2016-10-17 20:54   ` Khem Raj
2016-10-17 22:22     ` Michel D'HOOGE
2016-10-18  7:58   ` Jussi Kukkonen
2016-10-18 12:41     ` Michel D'HOOGE [this message]

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=1132601620.150136748.1476794472685.JavaMail.root@spooler3-g27.priv.proxad.net \
    --to=michel.dhooge@free.fr \
    --cc=yocto@yoctoproject.org \
    /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.