arlen_ has quit [Remote host closed the connection]
bq has quit [Remote host closed the connection]
xmn has quit [Ping timeout: 265 seconds]
jmiehe has quit [Quit: jmiehe]
sakoman has quit [Quit: Leaving.]
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
amitk has joined #yocto
kiran_ has quit [Ping timeout: 245 seconds]
pgowda has joined #yocto
mranostaj has quit [Quit: leaving]
mranostaj has joined #yocto
oobitots has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
ThomasD13 has joined #yocto
oobitots has quit [Ping timeout: 256 seconds]
davidinux has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
alejandrohs has quit [Read error: Connection reset by peer]
alejandrohs has joined #yocto
rfuentess has joined #yocto
Sion has joined #yocto
goliath has joined #yocto
ant__ has quit [Quit: Leaving]
rsalveti has quit [Quit: Connection closed for inactivity]
Wouter01008 has quit [Remote host closed the connection]
Wouter01008 has joined #yocto
<perdmann>
qschulz: Thanks for your help. sadly i forgot the name of the other guy who helped me :( But in the end it worked. I dont know exactly why but it makes a difference if i use ${TOPDIR} directly or the BBPATH variable ...
<perdmann>
with TOPDIR directly it works.
<JosefHolzmayrThe>
yo dudX
frieder has joined #yocto
frieder has quit [Ping timeout: 252 seconds]
roussinm has quit [Quit: WeeChat 3.3-dev]
mckoan|away is now known as mckoan
<mckoan>
good morning
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
frieder has joined #yocto
<kanavin_>
moto-timo, \0/ does it look nice?
rob_w has joined #yocto
leon-anavi has joined #yocto
vd has quit [Ping timeout: 256 seconds]
<mckoan>
#bringELCEbacktoEurope
goliath has quit [Quit: SIGSEGV]
dgriego1 has quit [Ping timeout: 252 seconds]
dgriego has joined #yocto
<qschulz>
jaskij[m]: interesting for the time needed to build the dot file, I had a 12-core CPU with 32GB of RAM at my previous job and it took hours to produce something totally unusable
zyga-mbp has joined #yocto
<qschulz>
jaskij[m]: I had issues moving from 4.14 to 5.4 on an i.MX8MM and it was due to a need for a different ATF version for 5.4
<qschulz>
BBPATH is a colon-separated list of paths, so that make sense yes. When you create a layer, you add your path to that list. So yes, using BBPATH is a bad idea :)
<jaskij[m]>
<qschulz> "jaskij: interesting for the time..." <- My image *is* fairly small, plus I've noticed that graphviz is purely single core (tbf, afaik that kind of stuff doesn't parallelize well, if at all). Which particular CPU? Many of those high core count chips have bad single core.
<qschulz>
perdmann: ^ (two messages above)
<qschulz>
jaskij[m]: i7-8700
<jaskij[m]>
qschulz: ATF? That acronym eludes me at the moment
<qschulz>
jaskij[m]: arm trusted firmware
<jaskij[m]>
Mhm. The issue here is that, I believe, you can't update the trusted firmware without updating the bios-like firmware for the embedded Cortex-M4. And that one is closed source, with binaries provided by the SoM vendor.
* qschulz
shrugs
<qschulz>
possibly
<qschulz>
jaskij[m]: quite funny that for a security feature you're stuck on an old kernel+atf :)
<jaskij[m]>
Yup. Thankfully this project is mostly part of a closed system. From what I've been told most of our deployments won't even have internet access
<qschulz>
jaskij[m]: Internet access is the most obvious way to get your device pwned but not the only one :)
<jaskij[m]>
Stuxnet comes to mind :D
xmn has joined #yocto
<jaskij[m]>
Hopefully we can move to an i.MX8MP SoM, that one shouldn't have an SDK older than 5.4
goliath has joined #yocto
<wCPO>
Can Yocto use only a single recipe from a layer and ignore all the other bbappend files??
<JosefHolzmayrThe>
wCPO: if one really wants that, BBMASK can probably be forced to do so.
<qschulz>
but if it's really only a single recipe, just take that one out of the layer and ditch it?
<qschulz>
JosefHolzmayrThe: stop linking the old doc website :D
<JosefHolzmayrThe>
qschulz: it says "latest" :P
zyga-mbp has joined #yocto
<qschulz>
JosefHolzmayrThe: good point... I'm still waiting for some freetime and CSS/HTML inspiration to code a big red header section on the old website
<qschulz>
and I would also want to have this header always stay at the top of the current view (not the page, the view), so that we can't miss it
<qschulz>
(and do the same change for the new docs for old releases too)
goliath has joined #yocto
<jaskij[m]>
new version does show it, although it isn't floating - guess that's what you want to change?
<JosefHolzmayrThe>
and make that header incorporate a link to the new one.
oobitots has quit [Quit: Client closed]
<qschulz>
jaskij[m]: yes
<qschulz>
JosefHolzmayrThe: yes
<qschulz>
jaskij[m]: the issue I have right now is with my limited CSS/HTML knowledge, I can have the header "floating
<qschulz>
" but it's over the current header
<qschulz>
which is useful since it gives you the button to open the navigation pane :)
camus1 has joined #yocto
<jaskij[m]>
I've long decided that CSS is black magic, the way it works
<jaskij[m]>
I'd sooner dive deep into BitBake's internals than learn CSS :P
camus has quit [Ping timeout: 245 seconds]
camus1 is now known as camus
<jaskij[m]>
(and I'm a noob at Python too)
zyga-mbp has joined #yocto
<jaskij[m]>
Run into a strange thing, and am not sure if and how to point it out to upstream: apparently, they have a maintenance branch, from which they cherry-picked into a CI/scan branch, and only tagged the release from there. Feels goddamn wrong, but it would be poking my nose into how they use Git and have their CI set up, so pointing it out feels wrong too.
<jaskij[m]>
there's two different commits which are identical, one in maintenance branch, the other in that CI/scan branch, and it's the second one tagged as a release.
<jaskij[m]>
or rather, not cherry picked but squashed
<jaskij[m]>
which bugs me way less
<ThomasD13>
Damn it. Yocto is not supported on Ubuntu 20.04 LTS ?
<jaskij[m]>
but still - branch names seem wrong
<jaskij[m]>
which Yocto?
<jaskij[m]>
as in, which version of Yocto?
<ThomasD13>
Ill have a look, one moment..
<jaskij[m]>
Dunfell (3.1) officially doesn't, Hardknott (3.3) does
<qschulz>
jaskij[m]: I think we have an issue there, 3.3 is pointing to the dev branch
<jaskij[m]>
qschulz: and 3.2 is showing the warning about outdated docs
<jaskij[m]>
I'd expect that if I only specify the minor, leaving out the patch, it'd redirect me to the latest patch
<ThomasD13>
I have a "vendor yocto configuration". Honestly I don't know which yocto version they use. Which layer does help me, to find out?
<jaskij[m]>
just check the branch
<jaskij[m]>
of poky or meta-oe
<qschulz>
jaskij[m]: 3.2 is EOL, so not incorrect to show the header ;)
<jaskij[m]>
qschulz: but 3.2.4 doesn't show it :P
<jaskij[m]>
I'd assumed it's on purpose because of how vendors love to ship outdated Yocto versions
<ThomasD13>
Okay, so oe-core is checkout on hardknott
<ThomasD13>
Puhhh... im lucky so far :D
<jaskij[m]>
hardknott does list 20.04 support in the manual
kayterina has quit [Ping timeout: 245 seconds]
Vonter has quit [Ping timeout: 265 seconds]
kayterina has joined #yocto
<jaskij[m]>
ThomasD13: you might be reading outdated manual, Google loves linking some truly ancient stuff, not to mention it seems to skip the new docs page entirely
<qschulz>
jaskij[m]: yeah ok, this needs some much deserved love
<qschulz>
we need to open an issue in Bugzilla
<qschulz>
well, a few :p
Vonter has joined #yocto
<jaskij[m]>
XD
<ThomasD13>
yes jaskij[m] I think that was the case :) thank you
<jaskij[m]>
qschulz: any way to tell Google to stop linking old pages? I'm still regularly linked to 2.4 and not infrequently to 1.6. I'm guessing no one is actually versed enough in Google Search Console to do it?
<qschulz>
jaskij[m]: I don't think so? We briefly complained about it months ago and I think the answer was "python folks has the same issue, so I don't see YP being able to deal with this successfully"
<jaskij[m]>
qschulz: After reading Wikipedia, GSC seems to to allow it, but someone would have to o actually register an account for the domain with Google and then know how to use their tools. And I'm not even sure the acc would be frew
<jaskij[m]>
*free
fbre has joined #yocto
Barry[m]1 has joined #yocto
kanavin has joined #yocto
xmn has quit [Ping timeout: 245 seconds]
kanavin_ has quit [Ping timeout: 252 seconds]
<qschulz>
ndec_: can we say that 3.4 is obsolete the day 3.5 is out in the docs?
<ndec_>
everything is possible!
<ndec_>
i think we still have a BZ to improve this piece of code in the docs website ;-)
camus has quit [Ping timeout: 245 seconds]
<ndec_>
hmm. shouldn't 3.2 be obsolete already?
camus has joined #yocto
<qschulz>
yes
<qschulz>
ndec_: how do you test the change to the switchers.js?
<qschulz>
s/the change/changes/
<ndec_>
it's not straightforward, we need to reproduce the whole doc structure, i used the script we have in the ab to rebuild all branches.
<qschulz>
ThomasD13: the error message says it cannot find master branch
<qschulz>
you go to the github repo and you see there's no master branch, but a main one
<ThomasD13>
ahhhhh.... a common error..
yates has quit [Remote host closed the connection]
fitzsim has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
<jaskij[m]>
qschulz: I might've been wrong. Our talk yesterday prompted me to re-check. Seems like the issue is not in SCFW or ATF, but rather a mismatch between U-Boot and kernel, or at least that's what I'm leaning towards currently. The vendor BSP for my SoM was built against what looks like pre-mainlaine Linux, or at least the device tree is completely different to what's in 5.4. And since U-Boot looks at that device tree, I'm getting a load of errors.
<jaskij[m]>
At least that's my current theory. I'll need to revisit this once I'm done with userspace - that's my priority right now, and it seems to be working fine with 4.14. Updating U-Boot is something I'm very much *not* looking forward too.
<qschulz>
jaskij[m]: device trees are different in U-Boot and kernel so not sure what would be the errors
<jaskij[m]>
they are?
<qschulz>
except if they do fixups of the kernel device tree from U-Boot
<qschulz>
jaskij[m]: they are different files, though they can be identical (they often aren't)
<jaskij[m]>
but yes, just before the message "Starting kernel..." I'm getting a bung of errors
kayterina has quit [Ping timeout: 252 seconds]
<qschulz>
jaskij[m]: I mean... technically you could probably use the same Device Tree but it's bound to fail at one point :)
<jaskij[m]>
truth
<fbre>
Hi! Anybody using the Linux rpmsg driver of the i.MX8 which communicates between ARM processor and M4 coprocessor?
<fbre>
I've seen data loss in the driver
kayterina has joined #yocto
kanavin_ has joined #yocto
kanavin has quit [Read error: Connection reset by peer]
Schlumpf has quit [Quit: Client closed]
<jaskij[m]>
what could throw an error like this:
<jaskij[m]>
`ignoring clock-controller@56010000 power-domains of unexpected length 8`?
<jaskij[m]>
found it
<jaskij[m]>
it's in U-Boot
rfuentess has quit [Remote host closed the connection]
jwillikers has joined #yocto
kanavin has joined #yocto
<jaskij[m]>
qschulz: thanks, you've made me re-check it, and lookit what I found. Seems like there *is* a fixup in U-Boot, and that's what's been throwing the errors at me. While disabling practically the whole device tree: https://pastebin.com/wQKGfP2D
ThomasD13 has quit [Ping timeout: 245 seconds]
<jaskij[m]>
the size of `power-domains` changed between vendor kernel and mainline 5.4
leon-anavi has quit [Remote host closed the connection]
kanavin_ has quit [Ping timeout: 246 seconds]
leon-anavi has joined #yocto
<jaskij[m]>
I'm half-tempted just to patch out that fixup
<qschulz>
worth a try :)
<jaskij[m]>
Yup
<jaskij[m]>
I wonder if I can damage the SoC by enabling an unpowered peripheral or something. Why the check/fixup is even there.
<JPEW>
Is m4-native allarch? I would expect it to differ on two different hosts
Sion has quit [Ping timeout: 240 seconds]
<RP>
JPEW: With it effectively reverted on the autobuilder, the build seems ok so far (but still going)
<RP>
JPEW: m4-native is not allarch, no
<RP>
JPEW: I can't decide if we need it or not. I'm wondering if some other fix we made removed the need for it
<JPEW>
RP: possibly
* JPEW
tries to find any such fixes
kayterina has quit [Remote host closed the connection]
<RP>
JPEW: I think if this was going to break, it would have already done so since different gcc versions will give different outhashes for native recipes
roussinm has joined #yocto
oobitots has joined #yocto
kiran_ has joined #yocto
<JPEW>
RP: Ya maybe... did you do a full revert? I can't really figure out how it might have been "fixed"
<RP>
JPEW: I made it use a fixed tag for both arches which gave me options if it exploded badly
rfuentess has joined #yocto
<RP>
(which effectively reverts it)
<JPEW>
RP: Sounds good
<RP>
JPEW: Do you remember our discussions about the new method we added to the server where we "force" an equivalent match? I'm wondering if that was the real fix there
<RP>
JPEW: I would do a full revert if the tests work and we agree it is the right way forward
<JPEW>
RP: Ya, I do remember that
dev1990 has joined #yocto
manuel1985 has joined #yocto
<RP>
JPEW: NFS made bitbake unhappy? I'd bet it did :)
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jwillikers has quit [Remote host closed the connection]
<RP>
JPEW: I did join the weekly call just in case people are around
<JPEW>
K
<Xagen>
if i wanted the checkout of a layer to be at a specific commit-id, is there a way to set that?
<tlwoerner>
vmeson: thanks! i was following the irc and knew what the topic of discussion would be :-)
camus1 has joined #yocto
alessioigor has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
arr has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<moto-timo>
kanavin_: beauty is in the eye of the beholder, but it does look clean and modern :)
<moto-timo>
kanavin ^^
* moto-timo
should figure out how to do screen captures in GNOME
<kanavin>
moto-timo, 'compared to sato' was implied :)
<moto-timo>
kanavin: I think phosh cleanly wins that comparison
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<moto-timo>
kanavin: the good news is squeekboard was not required, as there is a built-in keyboard stub
<kanavin>
moto-timo, nice :) as for screenshots, did you bring it up on physical HW?
<kanavin>
maybe qemu next?
<moto-timo>
kanavin: the bad news is it needed some X11 stuff
<moto-timo>
kanavin: yes, I will be launching a qemu build next
<moto-timo>
kanavin: yes, physical rpi4 HW
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
manuel1985 has quit [Quit: Leaving]
kranzo[m] has quit [Quit: You have been kicked for being idle]
frieder has quit [Read error: Connection reset by peer]
zpfvo has quit [Remote host closed the connection]
frieder has joined #yocto
goliath has quit [Quit: SIGSEGV]
johnt has joined #yocto
<qschulz>
ndec_: we have to be a bit more careful when tagging releases, 3.3 is "broken" as it's marked as "dev" instead of "3.3" because we forgot to update conf.py
<qschulz>
jaskij[m]: I implemented the 3.2 -> 3.2.4 redirect in the Yocto docs but I think it's a mistake
<qschulz>
to do so. Because 3.2 is actually a release too. Like 3.2 is basically a 3.2.0
oobitots has quit [Ping timeout: 256 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mckoan is now known as mckoan|away
<mckoan|away>
e
oobitots has joined #yocto
leon-anavi has quit [Quit: Leaving]
rsalveti has joined #yocto
goliath has joined #yocto
rfuentess has quit [Remote host closed the connection]
frieder has quit [Ping timeout: 265 seconds]
arr has quit [Ping timeout: 265 seconds]
arr has joined #yocto
<Wouter01008>
Howdy! Anyone experience with the npm.bbclass? I'm trying to build a package, but I need to copy the npm-shrinkwrap from the git repo of the npm package into the recipe and include it in SRC_URI to properly download the deps. Is there any way to use the npm-shrinkwrap from the git repo instead?
<Wouter01008>
If I don't copy the npm-shrinkwrap it'll error out: `npm ERR! Could not install from "{truncated}/git/node_modules/{vendor}/{dep}" as it does not contain a package.json file.`. The whole node_modules folder is non-existent.
florian has quit [Quit: Ex-Chat]
nateglims has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 264 seconds]
camus1 is now known as camus
pgowda has quit [Quit: Connection closed for inactivity]
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
ant__ has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
goliath has joined #yocto
<smurray>
RP: I can take a look at it later today
<RP>
smurray: I know you're travelling, sorry :/
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<smurray>
RP: I’m a bit surprised, our patch is pretty small now. It should be easy to fix
<RP>
smurray: I admit I haven't looked at what the patch is doing
<smurray>
RP: it’s a much tweaked version of an old patch to add an option to emit LAVA style results. At this point it’s probably low impact enough to upstream it, I just keep forgetting it
zyga-mbp has joined #yocto
<moto-timo>
smurray: sounds familiar :)
<smurray>
moto-timo: indeed ;)
zyga-mbp has quit [Client Quit]
<Wouter0100>
Is there some way to use `${B}` in defining SRC_URI? It seems to cause a loop, but I'm not sure if there's any other way to do so. The use-case is to first let a fetcher (`git://`) download some files, and then use that file in another fetcher (`npmsw://`). In this case the order would be really important, but I don't think this would be a viable
<Wouter0100>
solution?
vd has quit [Quit: Client closed]
behanw has quit [Quit: Connection closed for inactivity]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
<vd>
does if [ -n "${FOOBAR}" ] ; doo_rootfs[depends] += "somerecipe:task" ; fi work?
<vd>
or does it need to be done in python?
alessioigor has quit [Quit: alessioigor]
<kergoth>
a bitbake file isn't shell, you can't use shell constructs like that if statement
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
<kergoth>
anonymous python is your best bet there
alessioigor has joined #yocto
<kergoth>
see the bitbake user manual for the details on exactly what's allowed in our file format
alessioigor has quit [Remote host closed the connection]
<vd>
kergoth I was thinking about a function. Is there anonymous shell function?
<kergoth>
no
alessioigor has joined #yocto
<kergoth>
do_rootfs[depends] += isn't shell either
<kergoth>
you're trying to shoehorn bitbake into shell into bitbake, interleaving the two file formats. not going to happen
<vd>
ok I see, so python anonymous is the only option, got it
<kergoth>
yep
<vd>
thank you, I was a bit confused on the various syntaxes ^^
oobitots91 has quit [Ping timeout: 256 seconds]
<kergoth>
it's one file format, the bitbake one. when you define a "shell function" in bitbake you're just setting a bitbake variable and setting a flag to tell bitbake to execute it with a shell script.
<kergoth>
the bitbake user manual file format section is definitive
<kergoth>
(at least, what's there is)
<kergoth>
foo () { bar; } is the same as foo="bar"; foo[func] = "1"; foo[shell] = "1"; :)
<vd>
interesting!
<vd>
kergoth: how would you do the equivalent of `install -m 600 ${DEPLOY_DIR_IMAGE}/foo ${IMAGE_ROOTFS}/bar` in python, if that is possible?
<kergoth>
the whole point of the ability to write shell functions is to make that not necessary :) but python can call out to shell with bb.process.run()
<vd>
ho nevermind, I'll simply add a shell ROOTFS_POSTPROCESS_COMMAND from an anonymous python function.
<kergoth>
probably easiest, yeah
<kergoth>
the bitbake file format is not shell *or* python, it's its own format, that happens to allow for shell or python to run in particular contexts.
<yates>
why does yocto attempt to download some tarball when i provide a simple git url: SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git;protocol=git;"
<yates>
?
<vd>
(the whole point was to have do_rootfs[depends] and ROOTFS_POSTPROCESS_COMMAND appended conditionally)
<kergoth>
yates: mirroring. you have one or more mirrors enabled, and that's our how mirrors distribute git repositories today
<kergoth>
as tarballs
<yates>
kergoth: thanks, but how am i enabling mirroring?
<kergoth>
How would I know how you have your build configured?
<kergoth>
Check your distro
<kergoth>
poky enables use of yocto mirrors, iirc
<vd>
In shell, the best equivalent to python's `if d.getVar('FOO'):` would be `if [ -n "${FOO}" ]`, correct?
<yates>
kergoth: i appreciate your input but i have no idea what you are talking about, re "how would i know how you have your build configured".
<yates>
perhaps i should ask, "Hypothetically, if i intended mirros to be enabled, how would i do it/"
<yates>
?
<kergoth>
You're asking a question that's literally impossible to answer without context
<kergoth>
MIRRORS or PREMIRRORS are set in the metadata, does that help?
<kergoth>
it can be set anywhere
<kergoth>
*convention* dictates its often the distro
<yates>
are you referring to something in the build/conf?
<kergoth>
If you don't know what a distro is, I don't know how to help you
<kergoth>
See the yocto project documentation
<kergoth>
distros aren't generally in build/conf, no
<RP>
yates: anything can set those variables, a class, a distro config, an include file or probably other things
<RP>
yates: see what MIRRORS and PREMIRRORS are set to with bitbake-getvar or bitbake -e
<RP>
OE enables mirrors by default, not just poky
goliath has quit [Quit: SIGSEGV]
<kergoth>
ah, thanks for the clarification
<vd>
is it common for a bbclass to inherit core-image or is it preferred that the recipe does inherit core-image myclass
<vd>
?
<RP>
vd: either is fine, depends what you're doing
<vd>
RP: I want to share the code that I have in a recipe which does embed a few files like overlay images and customization like SSH port, etc.
johnt has left #yocto [WeeChat 3.2.1]
<RP>
vd: put another way, does myclass depend on core-image or is it independent ?
<yates>
RP: bitbake-getvar is not a command in my path
<RP>
yates: it is new for 3.4
<vd>
it will be more flexible in case you want to create a new recipe compared to bbappend the base one or requiring it
kiran_ has quit [Ping timeout: 246 seconds]
<RP>
vd: it it works separately, it gives others more possible options
<vd>
RP: myclass does customize IMAGE_INSTALL and IMAGE_FEATURES for example, but doesn't depend on it per-se
<RP>
vd: so putting it in the recipe is fine it if doesn't require it and have a hard dependency
<vd>
ok thank you
<vd>
If the recipe does 'inherit core-image myclass', can myclass check if core-image is inherited?
<RP>
vd: it can in anon python
<RP>
vd: you start to have to wonder if it should be requiring it at that point though
<vd>
RP: it's just that my system consist or basically creating recipes from two classes: "core-image" (for the images) and "bundle" for an update framework bundle recipes. Ideally I'd like to share my build configuration variables in both, i.e. "inherit myclass" from both core-image and bundle recipes.
<vd>
Does that make sense?
<yates>
so why is (eventually) this fetch failing when i have git cloned that url and can checkout that revision? http://paste.debian.net/1213633/
<yates>
it's a damn liar!
<RP>
yates: is that revision in the master branch?
<RP>
yates: that is not what I asked. You're saying the revision is in the repository which I do not doubt. I asked "is that revision in the master branch"
<RP>
yates: to be clear, bitbake is saying the revision is not in the branch specified. I suspect that rather than lying, it is in fact telling you quite plainly something which is true
amitk_ has joined #yocto
<RP>
yates: bitbake looks forward your apology ;-)
florian has quit [Ping timeout: 250 seconds]
amitk has quit [Ping timeout: 245 seconds]
<RP>
vd: you can do that, I'm not sure its a great idea but you know what you're doing better than me
<vd>
RP: well I would trust you more than more about what seems good or not for bitbake recipes ;-)
<vd>
RP: you would write two classes, myimage and mybundle, instead of a single myclass guessing what kind of recipe is being written?
<RP>
vd: probably, or three, one with the common parts shared by the two
<RP>
but I'm not writing them :)
<yates>
bitbake: i apologize, i was wrong, and i just can't live without you.. BABY COME BACK!!!
<vd>
RP: I've seen a lot of these actually. I guess they're the way to go, but it can feel kind of messy to have all these foo-common, foo-common-base, foo-base, etc... classes sometimes :/
<RP>
vd: pros and cons. I do agree and I have tried to clean up and simplify where we can
<meck[m]>
Hi, does anyone know if you can do something like "export FOO_class-native" from local.conf or auto.conf? I want to set a environment variable for any package that uses the host gcc, but it would be nice not to pollute the non native packages...