qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
mansandersson868 has joined #yocto
mansandersson86 has quit [Ping timeout: 244 seconds]
mansandersson868 is now known as mansandersson86
nerdboy has quit [Remote host closed the connection]
nerdboy has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
paulg has quit [Ping timeout: 252 seconds]
warthog9 has quit [Ping timeout: 252 seconds]
warthog9 has joined #yocto
thomas_34 has joined #yocto
ohos has joined #yocto
ptsneves has joined #yocto
olani- has quit [Ping timeout: 248 seconds]
savolla has joined #yocto
rfuentess has joined #yocto
Chaser has joined #yocto
ohos has quit [Quit: Client closed]
rob_w has joined #yocto
goliath has joined #yocto
olani has quit [Read error: Connection reset by peer]
ptsneves has quit [Ping timeout: 272 seconds]
mckoan|away is now known as mckoan
leon-anavi has joined #yocto
ptsneves has joined #yocto
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
zeemate has joined #yocto
jerrycash has quit [Remote host closed the connection]
jerrycash has joined #yocto
alperak has joined #yocto
olani has joined #yocto
olani- has joined #yocto
ptsneves has quit [Ping timeout: 276 seconds]
Kubu_work has joined #yocto
ptsneves has joined #yocto
Chaser has joined #yocto
ptsneves has quit [Ping timeout: 276 seconds]
olani_ has joined #yocto
vthor has quit [Excess Flood]
paulg has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
Guest65 has joined #yocto
<Guest65>
When kernel modules are being built, can I somehow add a flag to them? Is there something like this for example:
<Guest65>
KMODULE_CFLAGS += “-DCONFIG_FOO_ENABLE”
florian_kc has joined #yocto
olani- has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 276 seconds]
olani- has joined #yocto
olani- has quit [Remote host closed the connection]
olani- has joined #yocto
Guest65 has quit [Quit: Client closed]
thomas_34 has quit [*.net *.split]
GNUmoon has quit [*.net *.split]
florian_kc has joined #yocto
pasherring has joined #yocto
florian_kc is now known as florian
frieder has joined #yocto
ablu has quit [Ping timeout: 276 seconds]
ablu has joined #yocto
sakoman has quit [Ping timeout: 260 seconds]
tgamblin__ has joined #yocto
tgamblin_ has quit [Ping timeout: 252 seconds]
leonanavi has joined #yocto
leon-anavi has quit [Ping timeout: 252 seconds]
leonanavi has quit [Quit: Leaving]
bjdooks has quit [Remote host closed the connection]
bjdooks has joined #yocto
tgamblin__ is now known as tgamblin
frgo has quit [Read error: Connection reset by peer]
frgo_ has joined #yocto
ak77 has quit [Read error: Connection reset by peer]
ak77 has joined #yocto
cyxae has joined #yocto
vmeson has quit [Ping timeout: 252 seconds]
sakoman has joined #yocto
<pasherring>
Hey all! Could anyone give me a hint on how can I enable bb.note(), called from inside a bbclass python function to output to terminal (stdout or stderr, at this point I don't know which one is the right one)?
<pasherring>
I tried calling mainlogger.setLevel(logging.INFO) in the body of .lib/bb/__init__.py but that didn't seem to work.
rob_w has quit [Remote host closed the connection]
<rburton>
pasherring: what's the intention? to make logging always appear, or to change the log level to see more messages for debugging?
<pasherring>
rburton, I wanted to see INFO level messages directly on the terminal. -DDD also enables DEBUG logging level, which adds way too much noise.
<pasherring>
I've written a small class to deploy files to a debugfs and rootfs which I usually use over NFS. And I used bb.note to output some messages to the terminal when the task is executed. I could use bb.warn, but that adds the WARNING: decoration
<rburton>
pasherring: you probably want to fiddle bb.logger not bb.mainlogger
<rburton>
that defaults to the level of debug-2
<rburton>
oh try bb.verbnote()
vmeson has joined #yocto
florian_kc has joined #yocto
Kubu_work has quit [Ping timeout: 265 seconds]
vvn has joined #yocto
<pasherring>
rburton, I see... I still have some trouble reading bitbake's python code, i thought it would resolve to mainlogger. Even more so beucase I see that bb.logger has already INFO level debugging enabled.
rfuentess has quit [Remote host closed the connection]
ray-san has quit [Remote host closed the connection]
ray-san has joined #yocto
SandeepRaju has joined #yocto
ptsneves has joined #yocto
ray-san has quit [Remote host closed the connection]
olani_ has quit [Ping timeout: 248 seconds]
Kubu_work has joined #yocto
frieder has quit [Remote host closed the connection]
Vonter has quit [Quit: WeeChat 4.6.2]
Vonter has joined #yocto
Kubu_work has quit [Quit: Leaving.]
<mischief>
when considering overrides and an environment that supports building many different machines, if a recipe uses machine overrides, should it be using PACKAGE_ARCH = "${MACHINE_ARCH}"?
<RP>
mischief: in theory that should magically get set, but yes. I'm not sure how well the magic works
savolla has quit [Quit: WeeChat 4.6.3]
<mischief>
eh? there's magic that changes PACKAGE_ARCH if there's machine overrides?
<pasherring>
rburton, it was actually knotty filtering event NOTE messages. It has a sort of event loop with a python styled switch case that handles `logging.LogRecord`. Fiddling there did the trick =)
florian has quit [Quit: Ex-Chat]
<mischief>
RP: i do not think i've observed any magic happening like that. we've been debating whether we should actually be setting MACHINE_ARCH when overrides are used, or whether we should be avoiding MACHINE_ARCH due to having to build once per N machines where N is approaching 20
<mischief>
but i also realize using machine overrides without MACHINE_ARCH may create unstable metadata, and i'm wondering how bad that is
<RP>
mischief: it is bad and you want to avoid that
florian_kc has quit [Ping timeout: 252 seconds]
<mischief>
RP: specifically with any OVERRIDES or MACHINEOVERRIDES?
goliath has quit [Quit: SIGSEGV]
leon-anavi has joined #yocto
<RP>
mischief: any override
<RP>
mischief: sorry, machine overrides
<RP>
if you're using machine overrides, the recipe is machine specific
goliath has joined #yocto
<mischief>
so it sounds like the rule of thumb is: any machine override usage should also have PACKAGE_ARCH = "${MACHINE_ARCH}"
<RP>
correct
mckoan is now known as mckoan|away
<mischief>
and that would include any possible potentially non-override indirection, like PACKAGECONFIG:pn-.. = in a machine config too i assume
<mischief>
tricky.. i think we violate this a lot today :)
<RP>
there is code that will probably help you out and catch the common issues but certainly you'd never get a package feed to work for example
<RP>
it isn't the way it was designed to work, the cleanup code just got good enough people got lazy. See my email to Mike Crowe recently
<mischief>
ah, well, we've conveniently avoided that problem by having no on target package management and read-only rootfs
<mischief>
RP: where is said code to .. catch common issues?
<RP>
mischief: the sstate sysroot cleanup pieces
ardo has quit [Ping timeout: 244 seconds]
druppy has joined #yocto
ardo has joined #yocto
neo has joined #yocto
bjdooks has quit [Read error: Connection reset by peer]
bjdooks has joined #yocto
bjdooks has quit [Client Quit]
neo is now known as Fr4nk
bjdooks has joined #yocto
goliath has quit [Quit: SIGSEGV]
bjdooks has quit [Client Quit]
<RP>
I posted on the bitbake list about a bit of a performance issue in bitbake parsing in case anyone is interested
bjdooks has joined #yocto
<khem>
RP: weekly report mentions about Changes to workdir layout for unpack with significant impact on git fetcher is there a link to proposal
florian_kc has joined #yocto
SandeepRaju has quit [Quit: Client closed]
<RP>
khem: kanavin has a branch which is being experimented with atm
<kanavin>
it is work in progress, and there are known fails
Chaser_ has joined #yocto
Chaser has quit [Ping timeout: 276 seconds]
<khem>
ah thanks, I was searching mailing lists :)
<kanavin>
khem, the impact on layers is that they would have to drop S = "${WORKDIR}/git", and replace WORKDIR with UNPACKDIR in any remaining explicit S settings
<kanavin>
both can be done with a single sed command across the whole layer
<khem>
yeah it will be good a add a migration script along with this changeset
<kanavin>
I will send patches for meta-oe
<kanavin>
then the sources are no longer directly in WORKDIR, but rather under WORKDIR/sources/BP, both for tarballs and git checkouts
<khem>
thanks
Chaser_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Chaser has joined #yocto
leon-anavi has quit [Remote host closed the connection]
Articulus has joined #yocto
Kubu_work has joined #yocto
florian_kc is now known as florian
<usvi>
ERROR: Nothing PROVIDES 'kernel-module-ipt-owner'. Close matches: linux-ti-staging RPROVIDES kernel-module-ipt-owner
<usvi>
I have a recipe with RDEPENDS:${PN} = "iptables kernel-module-ipt-owner"
<usvi>
but it gives that PROVIDES error. what am I doing wrong?
<usvi>
(hmm, did I need the kernel version there in the module)
<rfs613>
hmm, so i've got a recipe that builds fine, but when I try to use 'devtool modify' on it, the source gets unpacked, but patch fails to apply.
<rfs613>
tried with --no-overrides but same patch failure
<rfs613>
and yet regular build applies the same patch without problem
<rfs613>
any tips for debugging this?
ptsneves has quit [Read error: Connection reset by peer]
ptsneves1 has joined #yocto
ptsneves1 is now known as ptsneves
micka has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
micka_ has joined #yocto
Fr4nk has quit [Quit: WeeChat 4.6.3]
<vmeson>
rfs613: I'm far from a devtool expert or even a frequent user but I've found that if you manually modify the patch to skip the problem recipes, then do the update, add the patches back and use devtool again, that can work.
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Guest65 has joined #yocto
Fr4nk has joined #yocto
<vmeson>
rfs613: * problem patches not problem recipes