<pope>
Does someone have an idea why I get the message "Root-NFS: no NFS server address" when I try to boot my yocto with NFS root? The nfsroot is specified in the bootargs and the kernel should be built with nfs client support. The NFS kernel server is running.
goliath has joined #yocto
xmn has quit [Read error: Connection reset by peer]
xmn has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus1 is now known as camus
xmn has quit [Ping timeout: 255 seconds]
thomas__ has joined #yocto
thomasd13 has quit [Ping timeout: 260 seconds]
mckoan_ is now known as mckoan
<mckoan>
good morning
<mckoan>
pope: show more details please
mborzecki has joined #yocto
rfuentess has joined #yocto
Schlumpf has joined #yocto
zpfvo has joined #yocto
leon-anavi has joined #yocto
AKN has joined #yocto
Haxxa has quit [Remote host closed the connection]
me28 has joined #yocto
Haxxa has joined #yocto
<me28>
From the documentation :
<me28>
IMAGE_INSTALL: Lists out the base set of packages from which to install from the Package Feeds area.
<me28>
PACKAGE_INSTALL: The final list of packages passed to the package manager for installation into the image.
<me28>
Where is the subtle difference between both ?
florian__ has joined #yocto
florian has joined #yocto
<mckoan>
me28: When working with an initial RAM filesystem (Initramfs) image, use the PACKAGE_INSTALL variable.
<me28>
OK. So the second one is for the initramfs, the first for the ("HD") image, correct ?
olani- has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<mckoan>
me28: IMAGE_INSTALL is the list of packages for any final image (except Initramfs)
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
olani- has joined #yocto
<me28>
mckoan Thanks for the clarification (if you'd know where -in the docs- I missed this info, feel free to mention a link)
<me28>
mckoan (possibly I just didn't fully understand the docs I had a look at)
d-s-e has joined #yocto
ptsneves has joined #yocto
ramax[m] has quit [Quit: You have been kicked for being idle]
<RP>
me28: PACKAGE_INSTALL is calculated internally by the system so is IMAGE_INSTALL with things like IMAGE_FEATURES added
markov_twain has quit [Ping timeout: 268 seconds]
markov_twain has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
JJones has joined #yocto
<pope>
mckoan: Love to, what detail are you looking for?
JJones has left #yocto [Leaving]
diego_r has joined #yocto
locutusofborg_ has joined #yocto
LocutusOfBorg has quit [Ping timeout: 265 seconds]
amelius has joined #yocto
<amelius>
hey, I'm trying to use a file generated by another recipe in my recipe that need the file in its recipe-sysroot, is ther any good way to do it. I tried add the other recipe to depends, but it does not find the file.
<ptsneves>
amelius: DEPENDS is the way to go. Where is that file being put in the sysroot, and how are you looking for it?
fvincenzo has joined #yocto
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
<ptsneves>
amelius: certain paths are not automatically put in the sysroot.
<mckoan>
pope: for example : root=/dev/nfs rw nfsroot=${serverip}:/tftpboot/fs,v3 ip=192.168.0.184:${serverip}:192.168.0.1:255.255.255.0:targetname:eth0:off
mckoan is now known as mckoan|away
<pope>
the first element of ip is the local ip (target)?
<pope>
if I use ip=dhcp and use a fix ip instead of
<pope>
.. $serverip it works
dmoseley has joined #yocto
Bhstalel has joined #yocto
<Bhstalel>
Hello
<Bhstalel>
Is this channel still active ?
<pope>
yes
<Bhstalel>
I have an exiting custom layer that has some classes I was working on privately (auto init manager files handling for systemd, sysvinit, also a class for kernel module auto setup and compilation, and others ...)
<Bhstalel>
Any guides about the daily meetings that happen in order to propose my work and contribute it to Poky ?
<ptsneves>
Hey guys. Given a recipe, what is more important in choosing the version picked by bitbake? A lower version number of a layer with higuer BBFILE_PRIORITY; or a higher version number from a lower priority BBFILE_PRIORITY layer?
<JaMa>
BBFILE_PRIORITY first, then version, then D_P unless P_V is specified which overrules all
goliath has quit [Quit: SIGSEGV]
d-s-e has quit [Quit: Konversation terminated!]
<ptsneves>
JaMa: Thank you! What is D_P?
<JaMa>
err, D_P is between BBFILE_PRIORITY and version, but not very useful anymore (as you usually cannot introduce negative D_P in your own layer, because that will usually have higher BBFILE_PRIORITY)
<JaMa>
DEFAULT_PREFERENCE
<ptsneves>
Oh never even came across it :O
<JaMa>
it was useful in oe-classic days, not so useful now I think I've even created a ticket long time ago about it
<RP>
JaMa: when you mentioned it I was wondering if we should drop it...
<ptsneves>
RP says " I'm going to close this as NOTABUG."
murych has quit [Read error: Connection reset by peer]
<RP>
ptsneves: it was behaving as intended and it wasn't clear how else it should behave...
murych has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
<ptsneves>
RP: Ah i see that "verified" is a "closed" status.
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<JaMa>
RP: there are 3 recipes with D_P in meta-oe all 3 kind of valid (python3-django 2.2.28 default and 3.2.12, 4.0.2 with negative D_P) and similarly 1 of 2 versions of nginx, but I don't know how many people actually choose between these and Khem can probably get away with the highest version being the default
<JaMa>
RP: so I wouldn't mind it being dropped, I'm not using it since 2012 it seems :)
diego_r has quit [Ping timeout: 260 seconds]
<JaMa>
in worst case people can set P_V in layer.conf if they have a layer with stable and devel recipes and maintain the preference as a set of P_Vs
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
amitk has joined #yocto
murych has quit [Read error: Connection reset by peer]
florian__ has joined #yocto
murych has joined #yocto
<RP>
JaMa: I guess the use was for unstable development versions? Those are unlikely to be split between layers?
murych has quit [Client Quit]
<JaMa>
RP: yes I was usually using it for unstable dev versions, the "issue" why I've created that ticket back than was when you need development version of something which exists already in e.g. oe-core
<RP>
JaMa: meta/classes-recipe/devupstream.bbclass: d.setVar("DEFAULT_PREFERENCE", "-1") is the core usage of it
<JaMa>
RP: if you want to provide such recipe, so that users of your layer can explicitly opt-in with P_V, but not everybody gets it by default and yocto-compatibility checker gets angry
<RP>
JaMa: right, it is all a bit messy :(
<RP>
I'd love to simplify it but not sure we'd all agree on how
<JaMa>
I agree that it's a bit messy and that simplification would be nice :)
<JaMa>
from my POV tying BBFILE_PRIORITY with layer position in BBLAYERS (and BBPATH) would help people more than removing D_P
<JaMa>
thanks to D_P not being used much it usually doesn't surprise people
<RP>
JaMa: the only way we're going to simplify will be by removing things. I would love to remove some of the priority pieces...
<JaMa>
but bbappend, bbclass, require, recipe priority IMHO confuses even significant portion of people here in this chat (end evil BSP will use BBMASK to achieve what they are trying to do :/)
<JaMa>
agreed, I would just start by removing BBFILE_PRIORITY (and assigning it dynamicaly based on order of layers in BBLAYERS variable)
<JaMa>
our setup script "mcf" is already overriding BBFILE_PRIORITY, because the versions in layer.conf don't work in our setup (e.g. you don't want to get different layers with the same BBFILE_PRIORITY into the mix and upstream layer maintainers cannot know in which environments they will end)
<applepi>
Morning all. I'm working on a board from a company called Xiphos, and I've got their build and my recipes all working, but I've got a patch I need to apply to the board's .dtsi file. I'm doing all of my builds in a docker container, including the checkout and all that, so I'd like to add a recipe to my meta-mycompany layer that patches the
<applepi>
xiphos kernel before it's built. Is this possible?
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
<JaMa>
applepi: usually .bbappend for their kernel recipe should work
amitk has quit [Ping timeout: 268 seconds]
rfuentess has quit [Remote host closed the connection]
<applepi>
So just stick a .bbappend file into their meta-xiphos/recipes-kernel/linux folder? I was IDEALLY hoping for a solution where I didn't need to touch their stuff so I could just bitbake and let everything checkout out and build, but I guess that may not be feasible.
<JaMa>
no into your meta-mycompany
<RP>
JaMa: In some ways I'd like to drop layer priority but I know that has it's own set of challenges
florian__ has quit [Ping timeout: 276 seconds]
Soopaman has quit [Quit: Leaving.]
<applepi>
JaMa - can you explain where I would put it? I'm a little confused how a .bbappend in my own meta layer affects another, I'm a bit of a yocto lightweight.
<applepi>
I can write my own recipes and configure stuff but that's about as far as my experience stretches and I must be googling the wrong things because I'm not seeing it
Soopaman has joined #yocto
<rburton>
the entire point of a bbappend is that it affects recipes in other layers :)
<rburton>
bitbake will parse the recipe and the "append" the parse with the contents of your bbappend
<applepi>
So their layout is meta-xiphos/recipes-kernel/linux/linux-xiphos_#.##.bb... would I put my bbappend in meta-xiphos/recipes-kernel/linux/linux-xiphos_#.##.bbappend?
<JaMa>
no, in meta-mycompany/recipes-kernel/linux/linux-xiphos_#.##.bbappend
<applepi>
oops, that's what I meant, meta-mycompany
thomas__ has quit [Ping timeout: 276 seconds]
<applepi>
and just use a do_configure_prepend I guess?
meego has joined #yocto
<JaMa>
you said patch before, patches belong to SRC_URI
<JaMa>
and do_patch will apply them automatically
<JaMa>
there are many examples of exactly this as this is probably most typical use of a .bbappend
<applepi>
oohhhh, I thought I would need to add the patching to a function
<applepi>
okay cool I think I get it now
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
roussinm1 has joined #yocto
<roussinm1>
rburton: so I got it working, nativesdk-src packages in sdk on kirkstone with this patch: https://pastebin.com/raw/q8ZkNpMU, although I can't submit it upstream since mickledore is going to be the new master, we will be upgrading at some point to it...hopefully I can upstream it if changes can easily be ported to master.
amitk has joined #yocto
markov_twain has quit [Quit: markov_twain]
Soopaman has quit [Quit: Leaving.]
Soopaman has joined #yocto
Thorn has quit [Ping timeout: 268 seconds]
florian__ has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
<JaMa>
"There are 143 possible work days left until the final release candidates for YP 4.2 needs to be released." that many? isn't it for 4.3?
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
<RP>
JaMa: that is clearly wrong as I'm building it any time now
Haxxa has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<khem>
JaMa: good question, with nginx I think idea was to keep both stable and mainline versions and right now stable is 1.22 and mainline is 1.23 so 1.21 should be deleted and perhaps 1.22 added if we need s LTS version
<khem>
for django maybe upgrade to 4.2 and drop older 4.x recipes