Re: [yocto] Trouble patching a package
On Fri, Apr 19, 2013 at 11:04:20PM +, Saridakis, Dean (US SSA) wrote:
> Seems like this ought to be pretty easy based on the docs - Not sure what
> I've got wrong. I've added an append to my layer w/
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> SRC_URI += "0001-yada-yada.patch"
>
> # Comment out while debugging
> #PRINC := "${@int(PRINC) + 1}"
>
> The append file is in BBFILES. The patch file is in the same dir as the
> append file (using a files sub-dir didn't help). Been doing "bitbake -c patch
> -f pkg" to test/debug. (pkg is canutils, which is autconf based)
Based on the path you're using, the patch needs to be in a subdir
relative to your append file. Specifically, the subdir needs to have
the same name as the package.
-Kevin
>
> Ran into a couple thing I didn't understand trying to debug. I tried adding
>
> do_patch_append() {
> bbnote "Got here "
> }
>
> to log my append file was getting picked up, but the parse failed.
>
> Didn't get errors if the patch file name was wrong. The log only has a git
> ls-remote (which seems a little odd).
>
> Any help would be appreciated.
>
> Dean
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Trouble patching a package
Seems like this ought to be pretty easy based on the docs - Not sure what I've
got wrong. I've added an append to my layer w/
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "0001-yada-yada.patch"
# Comment out while debugging
#PRINC := "${@int(PRINC) + 1}"
The append file is in BBFILES. The patch file is in the same dir as the append
file (using a files sub-dir didn't help). Been doing "bitbake -c patch -f pkg"
to test/debug. (pkg is canutils, which is autconf based)
Ran into a couple thing I didn't understand trying to debug. I tried adding
do_patch_append() {
bbnote "Got here "
}
to log my append file was getting picked up, but the parse failed.
Didn't get errors if the patch file name was wrong. The log only has a git
ls-remote (which seems a little odd).
Any help would be appreciated.
Dean
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] clarification about BSP layer names and bblayers.conf file?
On Fri, 2013-04-19 at 08:37 -0400, Robert P. J. Day wrote: > from section 1.1 of BSP developers guide: > > http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#bsp-layers > > first, it's not actually *required* that a layer name start with the > prefix "meta-", is it? pretty sure it's not and, if it isn't, that > should be made abundantly clear. it's fine to point out that it's a > well-established convention but it should still be mentioned > explicitly that it's not necessary. > Right, the naming isn't required and it would make sense to make that clear, I agree. > second, the BBLAYERS example there seems overly complicated and > potentially confusing to beginners. the fact that meta-yocto is listed > as NON_REMOVABLE might make readers wonder how they're supposed to > know that. why not go with something a lot more people will see, like, > say: > > BBLAYERS = ?" \ <-- and that looks like a typo >/usr/local/src/yocto/meta \ >/usr/local/src/yocto/meta-ti \ >" > > BBLAYERS_NON_REMOVABLE ?= " \ >/usr/local/src/yocto/meta \ >" > I agree - the whole NON_REMOVABLE thing doesn't add anything and should be removed - the example is just trying to show how to add a BSP layer - the rest just adds potential confusion. And, yeah, it's a typo.. > finally, the passing reference to layers that contain sub-BSP-layers > is good, but show an example, such as the fact that the meta-crownbay > layer.conf file has a dependency on meta-intel: > > ... > LAYERDEPENDS_crownbay = "intel" > > never pass up the opportunity to reinforce an idea with a few lines > of actual code. :-) > Agreed, but on the other hand we don't really want to be too intel-specific (I know, we have crownbay everywhere else, but anyway..) Tom > more shortly ... > > rday > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how strict are released BSP requirements?
On Fri, 2013-04-19 at 08:19 -0400, Robert P. J. Day wrote: > (aside: currently going through yocto BSP developer's guide with my > proofreader's beanie on so be prepared for a few BSP-related questions > today. you've been warned.) > > in section on BSP requirements: > > http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#released-bsp-requirements > > there are alleged requirements like the existence of README and > README.sources files, but it seems lots of layers at > http://layers.openembedded.org/layerindex/ don't have one or the other > of those files. could that explanation be refined a bit? or should > those layers suck it up and add all files that are allegedly > "required"? > I don't think there's a requirement that the layerindex contain only Yocto-compliant or released BSP layers, so talking about Yocto BSP requirements doesn't really apply... For Yocto-compliant BSPs, yes, the README is required. For released BSPs that contain binary images, README.sources is required, but since binary images are only recommended (see 1.3.2, this requirement should be moved from the required section to the recommended if binary images are included). In practice, both files are typically added to a BSP, so if images are shipped, they're covered. Tom > rday > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] clarification about BSP layer names and bblayers.conf file?
On Fri, Apr 19, 2013 at 8:37 AM, Robert P. J. Day wrote: > first, it's not actually *required* that a layer name start with the > prefix "meta-", is it? pretty sure it's not and, if it isn't, that > should be made abundantly clear. it's fine to point out that it's a > well-established convention but it should still be mentioned > explicitly that it's not necessary. If we agree that what we currently have is "version 1", and in-line with the philosophy of always throwing away "version 1", my gut feeling is that instead of poky being the base of everything and everything else added on top as layers, I believe the people running this project would start with openembedded-core as the base, with poky being simply one (of many) layers on top and therefore (properly) renamed to meta-poky. My point is that in an ideal world poky should be renamed, to follow the accepted convention; but since it isn't, it demonstrates that layers don't have to start with the "meta-*" prefix. > the fact that meta-yocto is listed > as NON_REMOVABLE might make readers wonder how they're supposed to > know that. why not go with something a lot more people will see, like, > say: > > BBLAYERS = ?" \ <-- and that looks like a typo >/usr/local/src/yocto/meta \ >/usr/local/src/yocto/meta-ti \ >" > > BBLAYERS_NON_REMOVABLE ?= " \ >/usr/local/src/yocto/meta \ >" The whole concept of "non-removable" layers seems redundant. If a person were trying to build an image for i.MX53 that makes use of TI's work, the meta-ti layer would be just as "non-removable" as any other, wouldn't it? ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] Fix FILESEXTRAPATHS, dir is "netbase-5.0"
On 04/19/2013 07:45 AM, Paul Barker wrote: On 19 April 2013 15:39, Robert P. J. Day wrote: i think i'll just leave this to the rpi folks. :-) I'm building for raspberrypi so I'll add this to my queue of things to look at. Just another note about the netbase, for 1.4 the interfaces file moved to init-ifupdown, so that file should move to a new recipe with bbappends for init-ifupdown-1.0. We just fixed meta-yocto for the beagleboard in the final 1.4 release. Sau! -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] writeup on the mechanics of FILESEXTRAPATHS and bbappend files
On Wed, Apr 17, 2013 at 11:42 AM, Paul Eggleton wrote: > On Wednesday 17 April 2013 11:39:09 Robert P. J. Day wrote: >> p.s. i think one of the manuals should mention chris larson's >> "bitbake-env" utility, which i use for debugging and explanations all >> the time. > > I'd rather wait until we actually integrate that into BitBake (i.e. provide it > with the BitBake source, which I hope we can look at within the next > development cycle). Is it as simple as including it in the contrib directory? > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libsnmp-dev in yocto built image
Thanks Paul,
I followed these instructions
https://github.com/gumstix/Gumstix-YoctoProject-Repo
The recipe was in
~/yocto/poky/meta-openembedded/meta-oe/recipes-extended/net-snmp/
net-snmp_5.7.1.bb
I'm using
BB version 1.15.1
Distro Poky 1.2.1
Cheers
2013/4/19 Paul Eggleton
> On Friday 19 April 2013 15:44:39 Katu Txakur wrote:
> > I want to include net-snmp in an image that I'm building with the Yocto
> > project (gumstix-console-image). When I add it net-snmp-client or server
> to
> > the local.conf I get this error when bitbake is creating the rootfs.
> >
> > Processing perl-module-text-soundex...
> >
> > error: Failed dependencies:
> >
> > net-snmp-server = ${EXTENDPV} is needed by net-snmp-dev-5.7.1-r0.armv7a
> >
> > net-snmp-client = ${EXTENDPV} is needed by net-snmp-dev-5.7.1-r0.armv7a
>
> We don't use EXTENDPV anymore; EXTENDPV is not defined and that's why
> you're
> seeing that unexpanded value. Where did you get your net-snmp recipe from?
> Which version of the build system are you using?
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] libsnmp-dev in yocto built image
On Friday 19 April 2013 15:44:39 Katu Txakur wrote:
> I want to include net-snmp in an image that I'm building with the Yocto
> project (gumstix-console-image). When I add it net-snmp-client or server to
> the local.conf I get this error when bitbake is creating the rootfs.
>
> Processing perl-module-text-soundex...
>
> error: Failed dependencies:
>
> net-snmp-server = ${EXTENDPV} is needed by net-snmp-dev-5.7.1-r0.armv7a
>
> net-snmp-client = ${EXTENDPV} is needed by net-snmp-dev-5.7.1-r0.armv7a
We don't use EXTENDPV anymore; EXTENDPV is not defined and that's why you're
seeing that unexpanded value. Where did you get your net-snmp recipe from?
Which version of the build system are you using?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Change in 'devshell' behaviour
On Fri, 2013-04-19 at 08:52 -0600, Gary Thomas wrote: > CAUTION!! giant security hole awaits! > > I've just discovered that recent Poky/Yocto runs 'devshell' as ROOT! > > If I run 'bitbake SOME-RECIPE -c devshell' with a somewhat older > metadata (poky rev 09359e6ec00901abfe49157f1f9730117b4d284b) > the shell is run using my user id. > > With a newer poky rev 90b98764555945a186562ca8d501a9585ce2b23f, > the shell runs as 'root'. > > This change came with this revision: > > commit 4dc31a327be1a506e78e1d028db08ceee22a216f > Author: Richard Purdie > Date: Thu Mar 28 13:17:12 2013 + > > base.bbclass: When we use fakeroot, also use it for devshell > > Its generally useful for devshell to end up in the fakeroot environment. > If > a user needs to exit it, PSEUDO_UNLOAD=1 works, its usually > harder to enter the envionment. > > [YOCTO #3374] > > (From OE-Core rev: e6ffc747a8ca5142c9bc6fbd2b06b5808bb38b02) > > Signed-off-by: Richard Purdie > > Isn't this a horrible security flaw? Or is 'fakeroot' actually safe? > The change description doesn't tell me why it's "useful". > > Whatever the case, to me at least it's very unnerving... I think the key word to look at here is "fake". You'll find you can't do anything nasty to your system you couldn't do as your normal user account and this is purely emulation. This "root" context is the one do_install, do_populate_sysroot and other tasks run under so that we can give files owners and permissions in the packages. We chose to give it more visibility since its actually useful for debugging several types of problems. For example, you can look around the rootfs from the rootfs task and see real users as it would get tarballed up. You can get your normal shell back with "PSEUDO_UNLOAD=1 bash", which is much easier than trying to get into the pseudo context in the first place. So please rest assured there is no security issue here. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any point in a single machine recipe using a machine-specific file?
On Fri, 19 Apr 2013, Tomas Frydrych wrote: > On 19/04/13 15:34, Robert P. J. Day wrote: > > On Fri, 19 Apr 2013, Tomas Frydrych wrote: > > > >> On 19/04/13 15:15, Robert P. J. Day wrote: > >>> i'd wonder, if you're building for a different machine, why are > >>> you including the meta-rpi layer? > >> > >> Because at a distro-level you often want to target different > >> architectures. > > > > yes, i appreciate that but, in *this* case, we're talking about a > > single machine with a single architecture. i'm pretty sure we're > > agreeing, i'm just pointing out that in this specific example, having > > a machine-specific subdirectory is overkill. > > BSP layers are not stand alone entities, they can never assume that > no other machines exist in the ecosystem they are pulled into. So, > no, it is most definitely not an overkill. I am not sure how else to > explain it, maybe fix up the RPI layer the way you intended locally > and build yourself a Qemu image, see what happens to your interfaces > file. no, no, i'm good with this -- is this point made emphatically anywhere in the existing docs? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any point in a single machine recipe using a machine-specific file?
On 19/04/13 15:34, Robert P. J. Day wrote: > On Fri, 19 Apr 2013, Tomas Frydrych wrote: > >> On 19/04/13 15:15, Robert P. J. Day wrote: >>> i'd wonder, if you're building for a different machine, why are >>> you including the meta-rpi layer? >> >> Because at a distro-level you often want to target different >> architectures. > > yes, i appreciate that but, in *this* case, we're talking about a > single machine with a single architecture. i'm pretty sure we're > agreeing, i'm just pointing out that in this specific example, having > a machine-specific subdirectory is overkill. BSP layers are not stand alone entities, they can never assume that no other machines exist in the ecosystem they are pulled into. So, no, it is most definitely not an overkill. I am not sure how else to explain it, maybe fix up the RPI layer the way you intended locally and build yourself a Qemu image, see what happens to your interfaces file. Tomas -- http://sleepfive.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Change in 'devshell' behaviour
CAUTION!! giant security hole awaits! I've just discovered that recent Poky/Yocto runs 'devshell' as ROOT! If I run 'bitbake SOME-RECIPE -c devshell' with a somewhat older metadata (poky rev 09359e6ec00901abfe49157f1f9730117b4d284b) the shell is run using my user id. With a newer poky rev 90b98764555945a186562ca8d501a9585ce2b23f, the shell runs as 'root'. This change came with this revision: commit 4dc31a327be1a506e78e1d028db08ceee22a216f Author: Richard Purdie Date: Thu Mar 28 13:17:12 2013 + base.bbclass: When we use fakeroot, also use it for devshell Its generally useful for devshell to end up in the fakeroot environment. If a user needs to exit it, PSEUDO_UNLOAD=1 works, its usually harder to enter the envionment. [YOCTO #3374] (From OE-Core rev: e6ffc747a8ca5142c9bc6fbd2b06b5808bb38b02) Signed-off-by: Richard Purdie Isn't this a horrible security flaw? Or is 'fakeroot' actually safe? The change description doesn't tell me why it's "useful". Whatever the case, to me at least it's very unnerving... -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] Fix FILESEXTRAPATHS, dir is "netbase-5.0"
On 19 April 2013 15:39, Robert P. J. Day wrote: > > i think i'll just leave this to the rpi folks. :-) > I'm building for raspberrypi so I'll add this to my queue of things to look at. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] libsnmp-dev in yocto built image
Hi,
I want to include net-snmp in an image that I'm building with the Yocto
project (gumstix-console-image). When I add it net-snmp-client or server to
the local.conf I get this error when bitbake is creating the rootfs.
Processing perl-module-text-soundex...
error: Failed dependencies:
net-snmp-server = ${EXTENDPV} is needed by net-snmp-dev-5.7.1-r0.armv7a
net-snmp-client = ${EXTENDPV} is needed by net-snmp-dev-5.7.1-r0.armv7a
eglibc-binary-localedata-de-de.iso88591 is needed by
locale-base-de-de.iso-8859-1-2.13-r20.armv7a
/home/katu/gumstix-yocto/build/tmp/sysroots/i686-linux/usr/bin/perl-native/perl
is needed by dpkg-1.15.8.7-r16.4.armv7a
I also want to include libsnmp-dev to include the agent_module_config.h in
my development enviroment.
Could somebody please give me a hand with this?
Thanks a lot
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] Fix FILESEXTRAPATHS, dir is "netbase-5.0"
On Fri, 19 Apr 2013, Martin Jansa wrote:
> On Fri, Apr 19, 2013 at 10:17:10AM -0400, Robert P. J. Day wrote:
> > On Fri, 19 Apr 2013, Martin Jansa wrote:
> >
> > > On Fri, Apr 19, 2013 at 09:35:18AM -0400, Robert P. J. Day wrote:
> > > >
> > > > The actual files subdirectory name is "netbase-5.0", not "netbase".
> > > >
> > > > Signed-off-by: Robert P. J. Day
> > > >
> > > > ---
> > > >
> > > > same fix was once applied to exactly the same recipe bbappend file
> > > > under meta-ti layer.
> > > >
> > > > diff --git a/recipes-core/netbase/netbase_5.0.bbappend
> > > > b/recipes-core/netbase/netbase_5.0.bbappend
> > > > index 36432f5..a3fbd33 100644
> > > > --- a/recipes-core/netbase/netbase_5.0.bbappend
> > > > +++ b/recipes-core/netbase/netbase_5.0.bbappend
> > > > @@ -1,3 +1,3 @@
> > > > -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > > > +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> > > > # Don't forget to bump PRINC if you update the extra files.
> > > > PRINC = "1"
> > >
> > > that's P or use BP, and fix PRINC when you're there..
> >
> > ok, pedantic question -- the comment suggests you're supposed to
> > increment PRINC "if you update the extra files". but i didn't, i just
> > made sure they're now being included. i guess that still counts, yes?
>
> I was talking about PRINC := "${@int(PRINC) + 1}"
i think i'll just leave this to the rpi folks. :-)
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any point in a single machine recipe using a machine-specific file?
On Fri, 19 Apr 2013, Tomas Frydrych wrote: > On 19/04/13 15:15, Robert P. J. Day wrote: > > i'd wonder, if you're building for a different machine, why are > > you including the meta-rpi layer? > > Because at a distro-level you often want to target different > architectures. yes, i appreciate that but, in *this* case, we're talking about a single machine with a single architecture. i'm pretty sure we're agreeing, i'm just pointing out that in this specific example, having a machine-specific subdirectory is overkill. in any case, is this point made in any of the existing documentation? since it seems kind of important to clarify. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any point in a single machine recipe using a machine-specific file?
On Fri, Apr 19, 2013 at 10:23:01AM -0400, Robert P. J. Day wrote: > On Fri, 19 Apr 2013, Tomas Frydrych wrote: > > > On 19/04/13 15:02, Burton, Ross wrote: > > > On 19 April 2013 14:49, Robert P. J. Day wrote: > > >> but in the case of the rpi, is there any value in putting the > > >> files under a machine-named subdirectory? of course it won't > > >> hurt, but is there any point to it? > > > > > > You could argue the clarity that it will bring if another machine > > > is added to the BSP - the maintainer will be forced to decide if > > > it's common across all machines that the BSP will service, or > > > truly is specific to a particular machine. > > > > No, no, no, this has nothing to do with clarity, it's the only way > > in which it can be done without breaking other machines. As Martin > > said, multiple BSP layers often are included at the same time, and > > if a config file pulled in by a BSP bbappend is not made machine > > specific (which is what the machine specific directory means), it > > will be installed for any machine that does not come with a higher > > priority bbappend that also overrides this file. > > ok, now we're getting somewhere -- so it would be *strongly* > *encouraged* to make all of these bbappend files machine-specific? > that is, if you want to avoid potential confusion down the road. i'm > still a bit queasy on the idea that you'd include so many layers that > this might be an issue but ... whatever. i mean, if i wasn't > specifically building for an rpi, i can't imagine why i'd include the > meta-rpi layer. This is my typical layer list meta-jama = "master:33e48de8cf588c9df80025339d7883e25a3e3fb8" meta-shr meta-aurora meta-fso meta-android = "webOS-ports/master:0fe4b5559335d24764260d47d3f60d68de502a61" meta-oe meta-efl meta-gnome meta-gpe meta-multimedia meta-networking meta-initramfs meta-systemd = "jansa/test:a5c0447694ddacab285f192e1d8e425f6899d6e3" meta-osmocombb meta-nokia meta-htc meta-palm meta-openmoko meta-samsung = "webOS-ports/master:0fe4b5559335d24764260d47d3f60d68de502a61" meta-browser = "jansa/test:359cdae903c3772796b4658dd3129742d9a76d05" meta-handheld = "jansa/spitz:68177884e36e08cb76f11048bdf8ee3435b75ea3" meta = "jansa/test:2ac95cf4581c963ae49bc6f7af430a05228c34bc" so I have at least 6 different BSPs with += 10 MACHINEs all these BSPs are playing nice together and that's how it should be.. IIRC Angstorm includes even more BSPs.. > > > As an additional point, the 'interfaces' file should not be included > > in a netbase bbappend, it's not part of the netbase base package ... > > I opened a bug against meta-yocto-bsp for this, but seems this is > > more wide spread. > > huh, you're right, i'd never noticed that. > > rday > > -- > > > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] Fix FILESEXTRAPATHS, dir is "netbase-5.0"
On Fri, Apr 19, 2013 at 10:17:10AM -0400, Robert P. J. Day wrote:
> On Fri, 19 Apr 2013, Martin Jansa wrote:
>
> > On Fri, Apr 19, 2013 at 09:35:18AM -0400, Robert P. J. Day wrote:
> > >
> > > The actual files subdirectory name is "netbase-5.0", not "netbase".
> > >
> > > Signed-off-by: Robert P. J. Day
> > >
> > > ---
> > >
> > > same fix was once applied to exactly the same recipe bbappend file
> > > under meta-ti layer.
> > >
> > > diff --git a/recipes-core/netbase/netbase_5.0.bbappend
> > > b/recipes-core/netbase/netbase_5.0.bbappend
> > > index 36432f5..a3fbd33 100644
> > > --- a/recipes-core/netbase/netbase_5.0.bbappend
> > > +++ b/recipes-core/netbase/netbase_5.0.bbappend
> > > @@ -1,3 +1,3 @@
> > > -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > > +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> > > # Don't forget to bump PRINC if you update the extra files.
> > > PRINC = "1"
> >
> > that's P or use BP, and fix PRINC when you're there..
>
> ok, pedantic question -- the comment suggests you're supposed to
> increment PRINC "if you update the extra files". but i didn't, i just
> made sure they're now being included. i guess that still counts, yes?
I was talking about PRINC := "${@int(PRINC) + 1}"
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any point in a single machine recipe using a machine-specific file?
On Fri, 19 Apr 2013, Tomas Frydrych wrote: > On 19/04/13 15:02, Burton, Ross wrote: > > On 19 April 2013 14:49, Robert P. J. Day wrote: > >> but in the case of the rpi, is there any value in putting the > >> files under a machine-named subdirectory? of course it won't > >> hurt, but is there any point to it? > > > > You could argue the clarity that it will bring if another machine > > is added to the BSP - the maintainer will be forced to decide if > > it's common across all machines that the BSP will service, or > > truly is specific to a particular machine. > > No, no, no, this has nothing to do with clarity, it's the only way > in which it can be done without breaking other machines. As Martin > said, multiple BSP layers often are included at the same time, and > if a config file pulled in by a BSP bbappend is not made machine > specific (which is what the machine specific directory means), it > will be installed for any machine that does not come with a higher > priority bbappend that also overrides this file. ok, now we're getting somewhere -- so it would be *strongly* *encouraged* to make all of these bbappend files machine-specific? that is, if you want to avoid potential confusion down the road. i'm still a bit queasy on the idea that you'd include so many layers that this might be an issue but ... whatever. i mean, if i wasn't specifically building for an rpi, i can't imagine why i'd include the meta-rpi layer. > As an additional point, the 'interfaces' file should not be included > in a netbase bbappend, it's not part of the netbase base package ... > I opened a bug against meta-yocto-bsp for this, but seems this is > more wide spread. huh, you're right, i'd never noticed that. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any point in a single machine recipe using a machine-specific file?
On 19/04/13 15:15, Robert P. J. Day wrote: > i'd wonder, if you're building for a different machine, why are > you including the meta-rpi layer? Because at a distro-level you often want to target different architectures. > best answer i'd be able to give is that it's not essential but it > won't hurt anything, which sounds kind of lame. :-) No, it's is essential that it is done this way, BSPs are for specific machines, so they should never install generic config files. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] Fix FILESEXTRAPATHS, dir is "netbase-5.0"
On Fri, 19 Apr 2013, Martin Jansa wrote:
> On Fri, Apr 19, 2013 at 09:35:18AM -0400, Robert P. J. Day wrote:
> >
> > The actual files subdirectory name is "netbase-5.0", not "netbase".
> >
> > Signed-off-by: Robert P. J. Day
> >
> > ---
> >
> > same fix was once applied to exactly the same recipe bbappend file
> > under meta-ti layer.
> >
> > diff --git a/recipes-core/netbase/netbase_5.0.bbappend
> > b/recipes-core/netbase/netbase_5.0.bbappend
> > index 36432f5..a3fbd33 100644
> > --- a/recipes-core/netbase/netbase_5.0.bbappend
> > +++ b/recipes-core/netbase/netbase_5.0.bbappend
> > @@ -1,3 +1,3 @@
> > -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> > # Don't forget to bump PRINC if you update the extra files.
> > PRINC = "1"
>
> that's P or use BP, and fix PRINC when you're there..
ok, pedantic question -- the comment suggests you're supposed to
increment PRINC "if you update the extra files". but i didn't, i just
made sure they're now being included. i guess that still counts, yes?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any point in a single machine recipe using a machine-specific file?
On 19/04/13 15:02, Burton, Ross wrote: > On 19 April 2013 14:49, Robert P. J. Day wrote: >> but in the case of the rpi, is there any value in putting the files >> under a machine-named subdirectory? of course it won't hurt, but is >> there any point to it? > > You could argue the clarity that it will bring if another machine is > added to the BSP - the maintainer will be forced to decide if it's > common across all machines that the BSP will service, or truly is > specific to a particular machine. No, no, no, this has nothing to do with clarity, it's the only way in which it can be done without breaking other machines. As Martin said, multiple BSP layers often are included at the same time, and if a config file pulled in by a BSP bbappend is not made machine specific (which is what the machine specific directory means), it will be installed for any machine that does not come with a higher priority bbappend that also overrides this file. As an additional point, the 'interfaces' file should not be included in a netbase bbappend, it's not part of the netbase base package ... I opened a bug against meta-yocto-bsp for this, but seems this is more wide spread. Tomas > > Ross > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- http://sleepfive.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any point in a single machine recipe using a machine-specific file?
On Fri, 19 Apr 2013, Burton, Ross wrote: > On 19 April 2013 14:49, Robert P. J. Day wrote: > > but in the case of the rpi, is there any value in putting the > > files under a machine-named subdirectory? of course it won't hurt, > > but is there any point to it? > > You could argue the clarity that it will bring if another machine is > added to the BSP - the maintainer will be forced to decide if it's > common across all machines that the BSP will service, or truly is > specific to a particular machine. yes, i understand that, but is there a convention? i just want to clarify that, in *this* case, there doesn't seem to be much value to adding that extra directory level. and addressing martin's point, sure, if one includes the rpi layer while building for another machine, it might make a difference, to which i'd wonder, if you're building for a different machine, why are you including the meta-rpi layer? from my perspective, it's a case of minimalism and being able to explain stuff to students. if a student looked at that meta-rpi netbase directory structure and asked why it was done that way, the best answer i'd be able to give is that it's not essential but it won't hurt anything, which sounds kind of lame. :-) rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any point in a single machine recipe using a machine-specific file?
On 19 April 2013 14:49, Robert P. J. Day wrote: > but in the case of the rpi, is there any value in putting the files > under a machine-named subdirectory? of course it won't hurt, but is > there any point to it? You could argue the clarity that it will bring if another machine is added to the BSP - the maintainer will be forced to decide if it's common across all machines that the BSP will service, or truly is specific to a particular machine. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] Fix FILESEXTRAPATHS, dir is "netbase-5.0"
On Fri, 19 Apr 2013, Martin Jansa wrote:
> On Fri, Apr 19, 2013 at 09:35:18AM -0400, Robert P. J. Day wrote:
> >
> > The actual files subdirectory name is "netbase-5.0", not "netbase".
> >
> > Signed-off-by: Robert P. J. Day
> >
> > ---
> >
> > same fix was once applied to exactly the same recipe bbappend file
> > under meta-ti layer.
> >
> > diff --git a/recipes-core/netbase/netbase_5.0.bbappend
> > b/recipes-core/netbase/netbase_5.0.bbappend
> > index 36432f5..a3fbd33 100644
> > --- a/recipes-core/netbase/netbase_5.0.bbappend
> > +++ b/recipes-core/netbase/netbase_5.0.bbappend
> > @@ -1,3 +1,3 @@
> > -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> > # Don't forget to bump PRINC if you update the extra files.
> > PRINC = "1"
>
> that's P or use BP, and fix PRINC when you're there..
ok, but i was just working off of *exactly* the same patch format
that went into meta-ti.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] any point in a single machine recipe using a machine-specific file?
On Fri, Apr 19, 2013 at 09:49:56AM -0400, Robert P. J. Day wrote: > > using the example i patched earlier, here's the file hierarchy for > raspberry pi's netbase recipe: > > ./netbase_5.0.bbappend > ./netbase-5.0 > ./netbase-5.0/raspberrypi > ./netbase-5.0/raspberrypi/interfaces > ./netbase-5.0/raspberrypi/hosts > > i understand the notion of a machine-specific subdirectory for > files, such as what you'd find under a layer like meta-ti which > defines multiple machines, so this is understandable for meta-ti: > > . > ./netbase_5.0.bbappend > ./netbase-5.0 > ./netbase-5.0/beagleboard > ./netbase-5.0/beagleboard/interfaces > > but in the case of the rpi, is there any value in putting the files > under a machine-named subdirectory? of course it won't hurt, but is > there any point to it? Yes, meta-rpi layer can be included when doing builds for different MACHINEs, raspberrypi subdirectory makes sure that their interfaces, hosts files are not used accidentaly -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] Fix FILESEXTRAPATHS, dir is "netbase-5.0"
On Fri, Apr 19, 2013 at 09:35:18AM -0400, Robert P. J. Day wrote:
>
> The actual files subdirectory name is "netbase-5.0", not "netbase".
>
> Signed-off-by: Robert P. J. Day
>
> ---
>
> same fix was once applied to exactly the same recipe bbappend file
> under meta-ti layer.
>
> diff --git a/recipes-core/netbase/netbase_5.0.bbappend
> b/recipes-core/netbase/netbase_5.0.bbappend
> index 36432f5..a3fbd33 100644
> --- a/recipes-core/netbase/netbase_5.0.bbappend
> +++ b/recipes-core/netbase/netbase_5.0.bbappend
> @@ -1,3 +1,3 @@
> -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> # Don't forget to bump PRINC if you update the extra files.
> PRINC = "1"
that's P or use BP, and fix PRINC when you're there..
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] any point in a single machine recipe using a machine-specific file?
using the example i patched earlier, here's the file hierarchy for raspberry pi's netbase recipe: ./netbase_5.0.bbappend ./netbase-5.0 ./netbase-5.0/raspberrypi ./netbase-5.0/raspberrypi/interfaces ./netbase-5.0/raspberrypi/hosts i understand the notion of a machine-specific subdirectory for files, such as what you'd find under a layer like meta-ti which defines multiple machines, so this is understandable for meta-ti: . ./netbase_5.0.bbappend ./netbase-5.0 ./netbase-5.0/beagleboard ./netbase-5.0/beagleboard/interfaces but in the case of the rpi, is there any value in putting the files under a machine-named subdirectory? of course it won't hurt, but is there any point to it? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH] Fix FILESEXTRAPATHS, dir is "netbase-5.0"
The actual files subdirectory name is "netbase-5.0", not "netbase".
Signed-off-by: Robert P. J. Day
---
same fix was once applied to exactly the same recipe bbappend file
under meta-ti layer.
diff --git a/recipes-core/netbase/netbase_5.0.bbappend
b/recipes-core/netbase/netbase_5.0.bbappend
index 36432f5..a3fbd33 100644
--- a/recipes-core/netbase/netbase_5.0.bbappend
+++ b/recipes-core/netbase/netbase_5.0.bbappend
@@ -1,3 +1,3 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
# Don't forget to bump PRINC if you update the extra files.
PRINC = "1"
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] clarification about BSP layer names and bblayers.conf file?
from section 1.1 of BSP developers guide: http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#bsp-layers first, it's not actually *required* that a layer name start with the prefix "meta-", is it? pretty sure it's not and, if it isn't, that should be made abundantly clear. it's fine to point out that it's a well-established convention but it should still be mentioned explicitly that it's not necessary. second, the BBLAYERS example there seems overly complicated and potentially confusing to beginners. the fact that meta-yocto is listed as NON_REMOVABLE might make readers wonder how they're supposed to know that. why not go with something a lot more people will see, like, say: BBLAYERS = ?" \ <-- and that looks like a typo /usr/local/src/yocto/meta \ /usr/local/src/yocto/meta-ti \ " BBLAYERS_NON_REMOVABLE ?= " \ /usr/local/src/yocto/meta \ " finally, the passing reference to layers that contain sub-BSP-layers is good, but show an example, such as the fact that the meta-crownbay layer.conf file has a dependency on meta-intel: ... LAYERDEPENDS_crownbay = "intel" never pass up the opportunity to reinforce an idea with a few lines of actual code. :-) more shortly ... rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] how strict are released BSP requirements?
(aside: currently going through yocto BSP developer's guide with my proofreader's beanie on so be prepared for a few BSP-related questions today. you've been warned.) in section on BSP requirements: http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#released-bsp-requirements there are alleged requirements like the existence of README and README.sources files, but it seems lots of layers at http://layers.openembedded.org/layerindex/ don't have one or the other of those files. could that explanation be refined a bit? or should those layers suck it up and add all files that are allegedly "required"? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-xilinx] PREFERRED_VERSION_linux-libc-headers = "3.6" getting ignored
On Friday 19 April 2013 11:44:49 Elvis Dowson wrote: >In my zynq-7-default-versions.inc file, I have the following > definitions for preferred versions > > PREFERRED_VERSION_virtual/kernel ?= "3.6" > PREFERRED_VERSION_linux-libc-headers = "3.6" > PREFERRED_VERSION_u-boot = "2012.10" > > However, when I build core-image-minimal, > PREFERRED_VERSION_linux-libc-headers = "3.6" gets ignored and it goes ahead > and builds linux-libc-headers_3.8.bb > > Is it only effective if specified in the local.conf file? No, it should be effective anywhere - unless it's being overridden later on. In recent versions of bitbake, the -e option will show for each variable how the final value got set, you should be able to see where it is being overridden from there. Alternatively with older versions you should just be able to "git grep" for the value in each of the layers you have enabled in order to find where it is being set. Are you sure you really need your own version of linux-libc-headers? Most of the time it is not necessary for the version to match that of the kernel you are using. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-xilinx] PREFERRED_VERSION_linux-libc-headers = "3.6" getting ignored
Hi, In my zynq-7-default-versions.inc file, I have the following definitions for preferred versions PREFERRED_VERSION_virtual/kernel ?= "3.6" PREFERRED_VERSION_linux-libc-headers = "3.6" PREFERRED_VERSION_u-boot = "2012.10" However, when I build core-image-minimal, PREFERRED_VERSION_linux-libc-headers = "3.6" gets ignored and it goes ahead and builds linux-libc-headers_3.8.bb Is it only effective if specified in the local.conf file? Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
