<tomzy_0>
I am having strange problem with networkmanager on kirkstone
<tomzy_0>
I set packageconfig to use ppp
<tomzy_0>
and configuration complains about missing /usr/sbin/pppd
<tomzy_0>
| Has header "pppd/pppd.h" : YES
<tomzy_0>
| Program pppd /sbin/pppd /usr/sbin/pppd found: NO
<tomzy_0>
|
<tomzy_0>
| ../NetworkManager-1.36.2/meson.build:570:4: ERROR: Assert failed: pppd required but not found, please provide a valid pppd path or use -Dppp=false to disable it
<tomzy_0>
ppp is in networmanager DEPENDS
<tomzy_0>
should not this be enough? I see that usr/sbin/pppd is missing in sysroot created for networkmanager
<qschulz>
tomzy_0: mmmmm, I'm wondering if this means there's a need to have ppp-native?
<qschulz>
why is it looking for the binary?
<rburton>
you can possibly just tell it a path
<rburton>
i guess it just wants to know where the pppd to run is, or will be
<ptsneves>
I had a look at it and i think it is the logger that needs to be configured in a way it does not show that. Last time i had a cursory look i did not see a direct way to quiten the logger
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
demirok has joined #yocto
florian has quit [Quit: Ex-Chat]
manuel1985 has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
florian_kc has quit [Ping timeout: 264 seconds]
prabhakarlad has quit [Quit: Client closed]
<qschulz>
ptsneves: I remember struggling to silence a logger from python modules, but in the end, redefining your own logger should be enough
<ptsneves>
ah so you think just redefining the logger at the bitbake-getvar level will do the trick? Will have a look. Have been trying to allocate time for Yocto contributions on my employer
<qschulz>
i did this a while ago so :/
<qschulz>
no memory except the code there
<qschulz>
I think it does not print warnings from python modules anymore but don't remember too much unfortunately :/
<qschulz>
maybe I had given up instead
<kergoth>
Check the bb.msg code for a function to ease it, otherwise you can just adjust the log level of the bitbake logger(s) directly the way you would any py thon logger (see the python logging module docs)
<ptsneves>
will try edditing bitbke-getvar's call to tinfoil
<moto-timo>
adding some kind of -q --quiet flag would be good
<kergoth>
agreed. alternatively, shift the warnings and errors to stderr. they *are* out of band from the intended use of the script, aft er all. if i'm calling getvar, i want the value of the variable, not a bunch of extras
<kergoth>
stderr isn't only for errors, but for anything out of band. *shrug*, either way, or both
<moto-timo>
I like that too
<kergoth>
iirc devtool or recipetool went that route for errorrs at least, if not warnings
<RP>
moto-timo: FWIW the postgres issue looks like it wants perl >= 5.36 and the dummy provides recipe has a version lower than 5
yssh has quit [Quit: Client closed]
<moto-timo>
RP: I tried it on kirkstone too and it wanted perl >= 5.34 as I recall. Not sure why we would ever have had dummy provide lower than 5 since perl5 has been the version for as long as I can remember.
<RP>
moto-timo: I think this bug has just been around a long time. We need to remove the version requirement. I think it is coming from shlibs in do_package
<dl9pf>
RP: systemd-network-generator.service seems to be my enemy
<dl9pf>
tries to be smart and auto-creates settings but then it takes down->up for dhcp the interface which is just dumb as a) it is configured already and b) netboot (aka rootfs) dies
seninha has quit [Quit: Leaving]
<RP>
dl9pf: I don't envy you trying to stop systemd doing something :(
<moto-timo>
RP: it's not the first time I wished PERLVERSION from perl-version.bbclass was available globally (lol). but that means recipes know about other recipes and meh
agrue has joined #yocto
<moto-timo>
RP: so the perl dummy version is being set by the PV of target-sdk-provides-dummy? e.g. that's where the 1.0 comes from... starting to see the light
<RP>
moto-timo: presumably, that is my assumption. Worryingly, setting the PROVIDES in dummy to perl (=5.36.0) doesn't help but does make it into the dummy rpm
<RP>
moto-timo: clearing the version is the only way I've made it work so far, setting PE and PV on the dummy recipe didn't help
<moto-timo>
RP: thank you for saving me trying that ;)
<moto-timo>
RP: could we somehow make the process_shlibs know it is in an SDK context and then drop the version check... <spitballing>
<RP>
moto-timo: the postgres rpm can't change depending on whether an SDK is being built or not
<moto-timo>
RP: right... so much for that bad idea :)
seninha has joined #yocto
<RP>
moto-timo: the version constraint fails since the dummy recipe injects into conflicts and replaces
Algotech13 has quit [Remote host closed the connection]
<RP>
moto-timo: I don't know what the right incantation is to make the versioning work :/
kscherer has quit [Quit: Konversation terminated!]