ChanServ changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2021.11) Nov 30 - Dec 2, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec
kiran_ has joined #yocto
GNUmoon has joined #yocto
kiran_ has quit [Ping timeout: 265 seconds]
prabhakarlad has joined #yocto
wesm has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
Wulf has quit [Ping timeout: 265 seconds]
Wulf has joined #yocto
goliath has quit [Quit: SIGSEGV]
xmn has quit [Quit: ZZZzzz…]
sakoman has quit [Quit: Leaving.]
geoffhp has joined #yocto
Saur has quit [Ping timeout: 268 seconds]
Saur has joined #yocto
sakoman has joined #yocto
prabhakarlad has quit [Quit: Client closed]
moosquito[m] has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
xmn has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
jwillikers has joined #yocto
jwillikers has quit [Remote host closed the connection]
vd has quit [Quit: Client closed]
vd has joined #yocto
xmn has quit [Ping timeout: 240 seconds]
<deuteron> I'm having a bit of trouble using AUTOREV in a recipe with multiple versions.
<deuteron> It seems like the revision gets mixed up between the versions which causes base hash mismatches galore.
<deuteron> Ah! It's probably this generate_revision_key function.
<deuteron> It just uses PN.
<deuteron> Hmmm, might be tricky to add PV since we're computing PV based on the hash.
sakoman has quit [Quit: Leaving.]
<deuteron> Actually, this whole appoarch is dumb. I don't need multiple recipe versions, I can just pass the branch to build from in via an environment variable.
camus1 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
camus1 has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus1 is now known as camus
vd has quit [Quit: Client closed]
vd has joined #yocto
kiran_ has joined #yocto
mariusz has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
davidinux has joined #yocto
kiran_ has quit [Ping timeout: 252 seconds]
rob_w has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
grma has quit [Ping timeout: 256 seconds]
vd has quit [Ping timeout: 256 seconds]
eloi has joined #yocto
GNUmoon has joined #yocto
F_Adrian has joined #yocto
GNUmoon has quit [Remote host closed the connection]
rfuentess has joined #yocto
GNUmoon has joined #yocto
creich has joined #yocto
kayterina has joined #yocto
<JosefHolzmayrThe> yo dudX
adrian_ has joined #yocto
zpfvo has joined #yocto
F_Adrian has quit [Ping timeout: 252 seconds]
pbergin has quit [Ping timeout: 240 seconds]
<qschulz> o/
mvlad has joined #yocto
pbergin has joined #yocto
locutusofborg_ is now known as locutusofborg
locutusofborg has joined #yocto
locutusofborg has quit [Changing host]
locutusofborg is now known as LocutusOfBorg
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
<qschulz> I'm confused, am I not supposed to be able to get DISTRO_FEATURES variable with bitbake -e ?
zpfvo has joined #yocto
<JosefHolzmayrThe> you should, AIUI
<qschulz> mmmmm, bitbake-getvar works but not bitbake -e anymore
<qschulz> wth
<qschulz> I don't have PACKAGE_CONFIG either
<qschulz> well, maybe because it's PACKAGECONFIG you idiot
<JosefHolzmayrThe> want me to confirm that? ;-)
<qschulz> mmmm, still not in bitbake -e
<qschulz> what am I doing wrong...
<qschulz> latest dunfell
<kroon_> qschulz, I've made the mistake several times of doing "bitbake -e | grep ^<some-variable>=", which fails for variables that are exported, "export <some-variable>="
<kroon_> not that DISTRO_FEATURES should be exported ...
<qschulz> kroon_: yes that was a good bet and a good think to note but that wans't it
<qschulz> I piped it to less and for some reason less didn't display all of it
leon-anavi has joined #yocto
<qschulz> so now the question is why is less misbehaving. Bad unix tool, bad, will get charcoal for christmas
<JosefHolzmayrThe> so in this case, less actually was less. not more.
<JosefHolzmayrThe> badum-tsh!
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
<qschulz> conclusion? I should start using bitbake-getvar more often :)
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
<kroon_> qschulz, what was the problem with less ?
zpfvo has joined #yocto
florian has joined #yocto
<qschulz> kroon_: it just didn't display the whole content of bitbake -e
<kroon_> so a bug in either bitbake or less ?
<qschulz> most likely less since I've been using bitbake -e | less for a while now
<qschulz> but not on the build machine I'm currently using
grma has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<kroon_> on the other hand, less has been around for a longer time and is probably used a lot more than bitbake in general
<rfuentess> rookie question with variable expansion for a `RDPEENDS_${PN}`. I have multiple packages that are on syntax ABCD-1, ABCD-2, ... ABC-N . If I want to add all of them as a dependency, do I do it with a inline Python variable expansion ?
<rfuentess> or there is a way to use a simple wildcard ?
<qschulz> rfuentess: is ${PN} created in the same recipe that ABCD-* packages are?
<rfuentess> yes. I mean, I want to add extra lines to the `RDEPENDS_${PN} =` So, yes. I consider the {PN} is created on that recipe
<rfuentess> (sorry, I'm still too green for all the terms of yocto)
zpfvo has quit [Remote host closed the connection]
<qschulz> rfuentess: how do you create your ABCD-* packages?
prabhakarlad has joined #yocto
<rfuentess> on this case they came from the default bitbake recommendations. Said recommendations are now disabled with `NO_RECOMMENDATIONS` but I still need some of them
<qschulz> if your ABCD-* packages all have a particular set of files that are regexp-able, I think this is a good way of doing it, by creating the packages on the fly and adding them to RDEPENDS of a main package
manuel1985 has joined #yocto
MauroAnjo has joined #yocto
<qschulz> the nice thing about this is that if you stick to the current convention you have (and which works with the dynamic packaging regexp, which isn't a given), any modification you do to the sources of the SW you build with the recipe will get the new packages automatically (i.e if in your source you add support for ABCD-N+1, you'll have a package created for this once you bump the ersion of the recipe)
<rfuentess> qschulz: thanks
<qschulz> rfuentess: but I want to make it clear that the package which RDEPENDS on ABCD absolutely NEEDS to be build by the same recipe building ABCD
<manuel1985> Can someone give me a quick intro to bitbake string manipulation? I want to split the variable ${manual_filename_deutsch} right before the extension and insert "+md5" + the first few digits of SRC_URI[deutsch.md5sum].
<manuel1985> Shall I use Python or does bitbake come up with something own?
<qschulz> manuel1985: just use python for this?
<kroon_> RP, ping
<RP> kroon_: hi
<kroon_> RP, can't we revert that nowadays ?
<RP> kroon_: nearly but not quite
<kroon_> RP, STAGING_BINDIR_NATIVE points to the build directories on my system, those paths usually dont even exist here since I use rm_work.bbclass
<RP> kroon_: The issue is that it shouldn't add things for dependencies of dependencies but reverting it would
prabhakarlad has quit [Quit: Client closed]
<qschulz> manuel1985: import pathlib; p = Path(d.getVar()); suffix = p.suffix; p = p.parent + p.stem; d.setVar(VAR, p + "+md5" + d.getVarFlag(SRC_URI, deutsch.md5sum) + suffix)
<qschulz> something like that I guess
<qschulz> in a function that you then call with MYVAR = "${@some_py_func(d)}"
<RP> kroon_: those paths would exist whilst the recipe is building though?
<kroon_> RP, no, not as I see it
<RP> kroon_: well, I think they do exist until rm_work runs (i.e. they're present during configure/compile/install)
<manuel1985> qschulz: Great, was just looking how to call Python from Bitbake. Thanks!
<manuel1985> Meant to utilize Pythons os.path, but pathlib seems more suitable.
pbergin has quit [Ping timeout: 265 seconds]
<manuel1985> Can I expect pathlib to be present on every Python installation? Otherwise I might go for a pure-python-text-functions based apprach.
<kroon_> RP, you're right, my bad
<qschulz> manuel1985: pathlib is part of python3 core libraries for some time already, and it's coming from your host distribution python (which you need installed AFAIR?)
camus has quit [Ping timeout: 268 seconds]
<qschulz> so I would say yes, if your Yocto is sufficiently recent, you can expect pathlib to be here, because we require python3
camus has joined #yocto
<manuel1985> qschulz: Perfect.
<qschulz> manuel1985: pathlib is availabhle since python 3.4
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
tnovotny has joined #yocto
<kanavin> RP: latest batch went really smoothly, thanks :)
<RP> kanavin: right, I just need to do something about my backlog in -next
<RP> kanavin: I did squash in the ruby tweak since I hate doing fixups as a separate patches if they haven't merged
<kanavin> RP: is something holding up this patch though? it passed a-full fine, several times https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/package-version-updates&id=a712899620f10eaf4ac6c00f799eb0e4a498fc2e
<kanavin> RP: squashinh is fine, it's just that I usually prefer doing fixups in separate commits, rather than sending v2, v3, v..., each time explaining what has been changed (and the actual change not being visible)
<manuel1985> qschulz: Does the text get inserted whereever "${@some_py_func(d)}" occured in the recipe, or do I need to explicitely write into a variable from inside the function? Guess d.setVar(VAR,... is doing that
<manuel1985> Am rn looking into parameterizing the function, as I need not only to read SRC_URI[deutsch.md5sum] but SRC_URI[english.md5sum]
zpfvo has joined #yocto
<RP> kanavin: I suspect that patch will break things whether the tests pass or not and I hven't been able to check yet
<RP> kanavin: just because the tests pass, it doesn't mean it is right, it can also mean the tests aren't good enough :/
<RP> kanavin: you've shrugged and tell me the tests are fine so I now need to do the checks I asked about
<kanavin> RP: wait, you said " Does this pass the sstate tests? I have a feeling it may encode a path into the
<kanavin> I just ran 'oe-selftest -r sstatetests' with this and they all passed.
<kanavin> sstate checksums :/
<kanavin> "
<kanavin> RP: and my answer was "I just ran 'oe-selftest -r sstatetests' with this and they all passed."
<kanavin> is there something I missed?
<RP> kanavin: well, ok, but I still suspect it hardcodeds buildpaths into sigdata so I don't trust the test :(
<RP> kanavin: that is why it is sitting, I need to try and explain what I'm thinking or check it or something
<RP> kanavin: I though I'd said I was worried about the data being encoded into the hashes
<RP> (which I am, I just suggested those selftest checks as the first way to check)
* RP is trying to do too many things at once :(
zpfvo has quit [Ping timeout: 265 seconds]
<RP> kanavin: sorry, I thought I had said about the data being encoded
<kanavin> RP: right, I can check that, but it wasn't entirely clear if the tests would catch this or if they pass, that it wouldn't be enough
<kanavin> there was no followup, so I'm asking
goliath has joined #yocto
<RP> kanavin: I'll reply on list but I've confirmed there is a problem :/
<kanavin> RP: thanks, apologies if it wasn't a good moment
<RP> kanavin: I've replied on list on how to visualise the problem and what we need to fix in the sstate tests too
<RP> kanavin: I was going through the patches so it is fine. I'm just struggling to keep up with patch review
zpfvo has joined #yocto
<RP> kanavin: hopefully I make sense. I'm not sure how we fix things but it at least explains my concern?
<kanavin> RP: yes, it does, I'll take it from there
kroon_ has quit [Quit: Leaving]
davidinux has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
prabhakarlad has joined #yocto
jwillikers has joined #yocto
jwillikers has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 252 seconds]
<ykrons> Hello
zpfvo has joined #yocto
<ykrons> A basic question: If I have a recipe that creates package A and B. If I include A in my image, will the whole recipe be executed and the package B created (even if not included in the final iamge) ?
<RP> ykrons: it will
<ykrons> RP: ok thanks for clarification!
pbergin has joined #yocto
<qschulz> manuel1985: MYVAR = "${@some_py_func(d)}" will assign it to the variable outside of a function, if you want inside a function, a simple d.setVar(MYVAR, some_py_func(d)) should do
<qschulz> manuel1985: your python function can have any number of parameters, just remember to pass "d" variable if you want to be able to access the datastore (where variables are stored, among other things)
<RP> kanavin: crazy thought - perhaps we should set some variable to contain the name of the layer being the current recipe being parsed is from
<RP> kanavin: we have a few of these "need to know where this is from" type changes. Although it could be a patch from a bbappend I guess
<ykrons> Another point: I have an issue with the watchdog-keepalive package. In the watchdog recipe, watchdog and watchdog-keepalive are flagged as conflicting. I have watchdog-keepalive in my image and everything goes well for the image, but when I build my SDK, I get a solver error because watchdog is included. Any idea I can avoid to have watchdog in the SDK ?
<manuel1985> qschulz: Alright, already came up with something I think is functional.
<manuel1985> One last question: How do I let my python function run, when not through ${@some_py_func(d)}?
<manuel1985> That is, when I use d.setVar() inside the function instead of the functions return value
tnovotny has quit [Quit: Leaving]
<RP> manuel1985: *when* do you want the function to run is the key question
JaMa has quit [Ping timeout: 256 seconds]
JaMa has joined #yocto
<qschulz> manuel1985: what RP said :) the key point being.. do you want to access this variable from more than one task? if yes, either go for "inline" python or add something in an anonymous python function (python __anonymous() )
The_Pacifist has quit [Ping timeout: 256 seconds]
The_Pacifist has joined #yocto
<qschulz> manuel1985: if only one task, you can call it from any python task
sakoman has joined #yocto
<qschulz> for shell tasks, there's probably a wrapper to call python tasks, I would check on the side of ROOTFS_POSTPROCESS_COMMAND I seem to recall there was something that caught my eye when going through the code
<kanavin> RP: perhaps there could be a singular BBFILE_COLLECTION set in layers and then appended to BBFILE_COLLECTIONS
<kanavin> currently:
<kanavin> BBFILE_COLLECTIONS += "gnome-layer"
<kanavin> which means that identifier loses specificity
<kanavin> that would also neatly sidestep the issue with paths poisoning the signature
vd has joined #yocto
<kanavin> RP: although this would break people's bbappends to core, as the upstream-status check will be enforced there too - I can imagine a flood of angry complaints :-/
<kanavin> maybe better to stick with path-based check
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
<ykrons> Is there a way to know why a package is included in an image ? In my case (watchdog package) I think it is due to a packagegroup included, but I can not find it.
<tgamblin> I am trying to add a ptest to libnftnl. I have a do_compile_ptest and do_install_ptest in the recipe file, RDEPENDS:{$PN}-ptest set, and "ptest" in the inherit line, but when I try and build libnftnl-ptest I get an error saying that nothing PROVIDES libnftnl-ptest, but that libnftnl RPROVIDES libnftnl-ptest. Does anyone know what to do to fix this?
kriive has joined #yocto
* JosefHolzmayrThe spots "nft"....
<tgamblin> JosefHolzmayrThe: thankfully not that kind :)
<RP> kanavin: we really need to lose the "collections" namespace pieces :/
<RP> kanavin: I'm torn on path vs. recipe location. Whilst it may annoy a few people initially I'm not sure that is a good reason not to do it. Just thinking out loud though...
<kanavin> RP: I tend to agree that it will force people to think about their private patches and how they want to handle them
<kanavin> and hopefuly with at least some organizations having the 4 eye principle, someone will ask questions when those patches are mass-marked as inappropriate or pending just to silence the check
prabhakarlad has quit [Quit: Client closed]
jpuhlman_ has joined #yocto
jpuhlman has quit [Ping timeout: 265 seconds]
<RP> kanavin: thanks for the oe-arch post, that is what I was thinking we'd need
rob_w has quit [Remote host closed the connection]
<qschulz> mmm getting pseudo aborts when building icu or ncurses on dunfell.. :/
<qschulz> ncurses do_install and icu do_configure for now only
<qschulz> link recursion too deep
<qschulz> nah that was unrelated, just path mismatch in pseudo.log :/
<qschulz> --tmpfs /tmp passed to Pyrex made it pass.. cc JPEW
mariusz has quit [Ping timeout: 240 seconds]
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
filipm[m] has quit [Quit: You have been kicked for being idle]
alicef has quit [Quit: install gentoo]
alicef has joined #yocto
alicef has quit [Quit: install gentoo]
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
alicef has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tartarus_ has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
eloi has quit [Ping timeout: 256 seconds]
Tartarus has quit []
Tartarus_ is now known as Tartarus
Tartarus has quit [Quit: Reconnecting]
Tartarus has joined #yocto
Tartarus has quit [Client Quit]
Tartarus has joined #yocto
Tokamak has joined #yocto
eloi has joined #yocto
bps has quit [Ping timeout: 240 seconds]
kiran_ has joined #yocto
MauroAnjo has quit [Quit: Client closed]
ferlzc has joined #yocto
<ferlzc> Hello, i'm creating an recipe on Yocto 3.3. is a simple Makefile project but the project needs "libpq-fe.h" to compile. I noticed that this dependency is provided by DEPENDS = "postgresql". But is not working
<ferlzc> any suggestions ?
<rburton> "simple" makefiles are harder than people think
<rburton> does it respect CC/CFLAGS/LDFLAGS from the environment? if not, it won't know where the sysroot is, so won't be able to find the headers
prabhakarlad has joined #yocto
MauroAnjo has joined #yocto
<ferlzc> I'm not sure... maybe I should replace some variables with EXTRA_OEMAKE or patch the Makefile
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rfuentess has quit [Remote host closed the connection]
dev1990 has joined #yocto
<rburton> can you share the makefile?
<rburton> and if you wrote it, the best solution is to not use make
<rburton> autotools, meson, even cmake are all better
Tokamak has joined #yocto
zpfvo has quit [Quit: Leaving.]
<qschulz> rburton: i'm surprised you put "even" for cmake and not autotools :D
<rburton> autotools isn't terrible
<RP> rburton: stockholm syndrome again :)
<rburton> haha
<RP> khem: I had a look at a few binutils patches and didn't like them :)
florian has quit [Quit: Ex-Chat]
bps has joined #yocto
bps has joined #yocto
MauroAnjo has quit [Quit: Client closed]
leon-anavi has quit [Quit: Leaving]
ferlzc has quit [Quit: Client closed]
pbergin has quit [Ping timeout: 265 seconds]
creich has quit [Remote host closed the connection]
kayterina has quit [Ping timeout: 252 seconds]
florian has joined #yocto
florian has quit [Ping timeout: 240 seconds]
vd has quit [Quit: Client closed]
vd has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<vd> quizz: FOO = "bar"; FOO:anactiveoverride += "baz"; ${FOO} will equal "bar baz" or "baz"?
florian has joined #yocto
pbergin has joined #yocto
<JaMa> " baz" if "anactiveoverride" is in OVERRIDES
<JaMa> "bar" if isn't, use "bitbake -e" or "bitbake-getVar" if in doubt
frieder has joined #yocto
frieder has quit [Remote host closed the connection]
florian has quit [Ping timeout: 240 seconds]
* rfs613 was just getting confused by this. Even though I recently did RTFM.
<rfs613> in my case it sure looks like it should append, but it doesn't.
<vd> rfs613 yeah it's tricky but you actually get the difference once you understand the difference between FOO:append:override and FOO:override:append
<wyre> where's usually set the kernel an image recipe will build? 🤔
<vd> wyre it's usually described in the machine configuration
<wyre> vd, I was guessing that ... but ... https://bpa.st/JY6Q I can't see it in the mine
<wyre> is it maybe into the geamx6.inc?
<vd> wyre you'd have to dig into the include files unfortunately yes
Tokamak has quit [Read error: Connection reset by peer]
<vd> until you find a PREFERRED_PROVIDER_virtual/kernel for example
<wyre> sure, vd thank you very much, it was in there 😜
mvlad has quit [Remote host closed the connection]
jpuhlman_ has quit [Remote host closed the connection]
jpuhlman_ has joined #yocto
florian has joined #yocto
Tokamak has joined #yocto
<rfs613> is there a REPL where one can try out variable expansions that bitbake would perform?
<rfs613> (yes, I can edit a .bb file, and then run bitbake -e on it... but it's 30 seconds each time to parse 2800 recipes...)
<manuel1985> rfs613: Are you testing them by changin local.conf? Sounds like, as the local.conf is inherited into all the recipes there are, I think
Dhruvagole[m] has quit [Ping timeout: 268 seconds]
<manuel1985> You might be faster with putting them in one recipe, and only letting bitbake build this one recipe
hjones2199[m] has quit [Ping timeout: 240 seconds]
jordemort has quit [Ping timeout: 240 seconds]
JosefHolzmayrThe has quit [Ping timeout: 250 seconds]
glembo[m] has quit [Ping timeout: 252 seconds]
Jari[m] has quit [Ping timeout: 252 seconds]
Saur[m] has quit [Ping timeout: 252 seconds]
<rfs613> I'm trying with 'bitbake -e -b mytest.bb' currently....
jaskij[m] has quit [Ping timeout: 260 seconds]
nrossi[m] has quit [Ping timeout: 250 seconds]
FredericOuellet[ has quit [Ping timeout: 250 seconds]
khem has quit [Ping timeout: 250 seconds]
coldspark29[m] has quit [Ping timeout: 250 seconds]
Tartarus has quit [Ping timeout: 260 seconds]
nodeboy[m] has quit [Ping timeout: 250 seconds]
Epictek[m] has quit [Ping timeout: 250 seconds]
zagor has quit [Ping timeout: 260 seconds]
PascalBach[m] has quit [Ping timeout: 260 seconds]
kayterina[m] has quit [Ping timeout: 240 seconds]
sinic[m] has quit [Ping timeout: 240 seconds]
jqua[m] has quit [Ping timeout: 252 seconds]
Barry[m] has quit [Ping timeout: 250 seconds]
dwagenk has quit [Ping timeout: 250 seconds]
Alban[m] has quit [Ping timeout: 250 seconds]
rzr has quit [Read error: Connection reset by peer]
Emantor[m] has quit [Ping timeout: 245 seconds]
barath has quit [Ping timeout: 250 seconds]
jonesv[m] has quit [Ping timeout: 240 seconds]
lexano[m] has quit [Ping timeout: 240 seconds]
suy|m has quit [Ping timeout: 240 seconds]
alvaropg[m] has quit [Ping timeout: 240 seconds]
an_sensr[m] has quit [Ping timeout: 260 seconds]
cperon has quit [Ping timeout: 260 seconds]
Perceval[m] has quit [Ping timeout: 260 seconds]
dxtrmrgn[m] has quit [Ping timeout: 260 seconds]
WadeBerrier[m] has quit [Ping timeout: 260 seconds]
hpsy[m] has quit [Ping timeout: 260 seconds]
Spectrejan[m] has quit [Ping timeout: 260 seconds]
ejoerns[m] has quit [Ping timeout: 250 seconds]
hmw[m] has quit [Ping timeout: 252 seconds]
moto_timo[m] has quit [Ping timeout: 252 seconds]
moosquito[m] has quit [Ping timeout: 265 seconds]
t_unix[m] has quit [Ping timeout: 265 seconds]
agherzan has quit [Ping timeout: 260 seconds]
ericson2314 has quit [Ping timeout: 268 seconds]
jwillikers[m] has quit [Ping timeout: 268 seconds]
berton[m] has quit [Ping timeout: 268 seconds]
olani[m] has quit [Ping timeout: 268 seconds]
JavierPeces[m] has quit [Ping timeout: 268 seconds]
shoragan[m] has quit [Ping timeout: 268 seconds]
mariusz has joined #yocto
dxtrmrgn[m] has joined #yocto
Spectrejan[m] has joined #yocto
alvaropg[m] has joined #yocto
WadeBerrier[m] has joined #yocto
hmw[m] has joined #yocto
cperon has joined #yocto
an_sensr[m] has joined #yocto
Perceval[m] has joined #yocto
moto_timo[m] has joined #yocto
t_unix[m] has joined #yocto
Emantor[m] has joined #yocto
rzr has joined #yocto
adrian__ has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
suy|m has joined #yocto
jonesv[m] has joined #yocto
adrian_ has quit [Ping timeout: 252 seconds]
F_Adrian has joined #yocto
adrian__ has quit [Ping timeout: 250 seconds]
jwillikers[m] has joined #yocto
adrian_ has joined #yocto
F_Adrian has quit [Ping timeout: 240 seconds]
JavierPeces[m] has joined #yocto
olani[m] has joined #yocto
shoragan[m] has joined #yocto
sinic[m] has joined #yocto
hjones2199[m] has joined #yocto
Dhruvagole[m] has joined #yocto
<wesm> Hi, I'm trying to make a recipe for a meson built package (https://git.sr.ht/~exec64/imv) but it's failing to find a 'opengl' dependency. I have opengl in my local.conf DISTRO_FEATURES and I don't see any other package that provides opengl or libOpenGL
lexano[m] has joined #yocto
jordemort has joined #yocto
Saur[m] has joined #yocto
nrossi[m] has joined #yocto
<wesm> what does DISTRO_FEATURES 'opengl' provide?
FredericOuellet[ has joined #yocto
glembo[m] has joined #yocto
Jari[m] has joined #yocto
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
jaskij[m] has joined #yocto
florian has quit [Ping timeout: 240 seconds]
<vd> wesm it provides to ability to configure packages with opengl support enabled, e.g.: https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtbase_git.bb#L51
<RP> qschulz: it is PACKAGECONFIG ?
<RP> qschulz: sorry, scrolling issues!
<vd> how can I prevent an image recipe from builing built for a given distro again?
<RP> vd: make it raise SkipRecipe in the cases you don't want it to exist?
<vd> RP: ho ok you raise an error from the image recipe itself for this release, I was thinking the other way around
<vd> Like adding this recipe name to a variable in the distro configuration file
<RP> vd: well there are lots of ways you could do it, I gave you one. You didn't specify you wanted to do it from a distro config.
berton[m] has joined #yocto
ericson2314 has joined #yocto
<vd> RP: I'm not sure, I just wanted to know the options available. I should've been clearer.
<vd> From the recipe is fine, so that I can also prevent a private application to be package into a customer image for example
Habbie has quit [Ping timeout: 245 seconds]
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
agherzan has joined #yocto
<wesm> vd: but it doesn't provide the opengl library? meson's `dependency('gl')` (and 'opengl') is returning false
<wesm> it's ultimately a call to `pkg-config --modversion opengl`
GNUmoon has joined #yocto
adrian_ has quit [Read error: Connection reset by peer]
florian has joined #yocto
<wesm> if I understand right then the DISTRO_FEATURES setting is just a flag other recipes can check to know if they should enable their gl support
Tartarus has joined #yocto
<wesm> but then how do I get libopengl or whatever this pkg-config call is looking for?
kayterina[m] has joined #yocto
xmn has joined #yocto
kayterina[m] has quit [Read error: Connection reset by peer]
Tartarus has quit [Read error: Connection reset by peer]
agherzan has quit [Remote host closed the connection]
ericson2314 has quit [Write error: Connection reset by peer]
berton[m] has quit [Write error: Connection reset by peer]
dxtrmrgn[m] has quit [Write error: Connection reset by peer]
lexano[m] has quit [Read error: Connection reset by peer]
suy|m has quit [Write error: Connection reset by peer]
jaskij[m] has quit [Remote host closed the connection]
glembo[m] has quit [Read error: Connection reset by peer]
Jari[m] has quit [Read error: Connection reset by peer]
sinic[m] has quit [Write error: Connection reset by peer]
jordemort has quit [Write error: Connection reset by peer]
JavierPeces[m] has quit [Read error: Connection reset by peer]
t_unix[m] has quit [Write error: Connection reset by peer]
Spectrejan[m] has quit [Read error: Connection reset by peer]
FredericOuellet[ has quit [Write error: Connection reset by peer]
Saur[m] has quit [Write error: Connection reset by peer]
moto_timo[m] has quit [Read error: Connection reset by peer]
hmw[m] has quit [Write error: Connection reset by peer]
Dhruvagole[m] has quit [Read error: Connection reset by peer]
jwillikers[m] has quit [Write error: Connection reset by peer]
alvaropg[m] has quit [Write error: Connection reset by peer]
an_sensr[m] has quit [Read error: Connection reset by peer]
hjones2199[m] has quit [Remote host closed the connection]
Emantor[m] has quit [Read error: Connection reset by peer]
shoragan[m] has quit [Read error: Connection reset by peer]
nrossi[m] has quit [Write error: Connection reset by peer]
Perceval[m] has quit [Read error: Connection reset by peer]
WadeBerrier[m] has quit [Read error: Connection reset by peer]
cperon has quit [Read error: Connection reset by peer]
jonesv[m] has quit [Write error: Connection reset by peer]
olani[m] has quit [Read error: Connection reset by peer]
Spectrejan[m] has joined #yocto
jordemort has joined #yocto
mariusz has quit [Ping timeout: 240 seconds]
pbergin has quit [Remote host closed the connection]
pbergin has joined #yocto
goliath has quit [Quit: SIGSEGV]
khem has joined #yocto
ejoerns[m] has joined #yocto
moto_timo[m] has joined #yocto
shoragan[m] has joined #yocto
Emantor[m] has joined #yocto
t_unix[m] has joined #yocto
Tartarus has joined #yocto
dwagenk has joined #yocto
barath has joined #yocto
zagor has joined #yocto
jonesv[m] has joined #yocto
jwillikers[m] has joined #yocto
Barry[m] has joined #yocto
FredericOuellet[ has joined #yocto
hmw[m] has joined #yocto
JosefHolzmayrThe has joined #yocto
suy|m has joined #yocto
hpsy[m] has joined #yocto
Dhruvagole[m] has joined #yocto
berton[m] has joined #yocto
ericson2314 has joined #yocto
alvaropg[m] has joined #yocto
Jari[m] has joined #yocto
cperon has joined #yocto
hjones2199[m] has joined #yocto
Epictek[m] has joined #yocto
nrossi[m] has joined #yocto
jqua[m] has joined #yocto
dxtrmrgn[m] has joined #yocto
Saur[m] has joined #yocto
coldspark29[m] has joined #yocto
glembo[m] has joined #yocto
WadeBerrier[m] has joined #yocto
JavierPeces[m] has joined #yocto
PascalBach[m] has joined #yocto
jaskij[m] has joined #yocto
Perceval[m] has joined #yocto
nodeboy[m] has joined #yocto
an_sensr[m] has joined #yocto
agherzan has joined #yocto
moosquito[m] has joined #yocto
sinic[m] has joined #yocto
olani[m] has joined #yocto
Habbie has joined #yocto
jordemort has quit [Quit: Client limit exceeded: 20000]
shoragan[m] has quit [Quit: Client limit exceeded: 20000]
Barry[m] has quit [Quit: Client limit exceeded: 20000]
zagor has quit [Quit: Client limit exceeded: 20000]
ericson2314 has quit [Quit: Client limit exceeded: 20000]
Tartarus has quit [Quit: Client limit exceeded: 20000]
Emantor[m] has quit [Quit: Client limit exceeded: 20000]
t_unix[m] has quit [Quit: Client limit exceeded: 20000]
Spectrejan[m] has quit [Quit: Client limit exceeded: 20000]
cperon has quit [Quit: Client limit exceeded: 20000]
jonesv[m] has quit [Quit: Client limit exceeded: 20000]
dwagenk has quit [Quit: Client limit exceeded: 20000]
Tartarus has joined #yocto
lexano[m] has joined #yocto
kayterina[m] has joined #yocto
Alban[m] has joined #yocto
JosefHolzmayrThe has quit [Quit: Client limit exceeded: 20000]
nrossi[m] has quit [Quit: Client limit exceeded: 20000]
Dhruvagole[m] has quit [Quit: Client limit exceeded: 20000]
barath has quit [Quit: Client limit exceeded: 20000]
lexano[m] has quit [Quit: Client limit exceeded: 20000]
florian has quit [Ping timeout: 250 seconds]
pbergin has quit [Remote host closed the connection]
pbergin has joined #yocto
Epictek[m] has quit [Quit: Client limit exceeded: 20000]
pbergin has quit [Remote host closed the connection]
pbergin has joined #yocto
creich has joined #yocto
pbergin has quit [Remote host closed the connection]
pbergin has joined #yocto
dvorkindmitry has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
eloi has quit [Ping timeout: 265 seconds]
suy|m has quit [Quit: Client limit exceeded: 20000]
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto