<cslcm>
hi - I have a recipe which pulls in cmake (via inherit), and i have protobuf as a dependency. But I need protoc (protobuf compiler) from protobuf available and cmake can't see it - anyone got any pointers?
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
<khem>
cslcm: add DEPENDS on protobuf-c-native protobuf-c
RobW has joined #yocto
<cslcm>
ah i need the native package.. that makes sense >.>
<cslcm>
ty
sotaoverride has quit [Ping timeout: 260 seconds]
sotaoverride has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
starblue has quit [Ping timeout: 245 seconds]
RobW has quit [Read error: Connection reset by peer]
starblue has joined #yocto
RobW has joined #yocto
Estrella has quit [Remote host closed the connection]
Estrella has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
otavio has quit [Ping timeout: 260 seconds]
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
dvergatal has quit [Read error: Connection reset by peer]
jclsn has quit [Ping timeout: 245 seconds]
dvergatal has joined #yocto
jclsn has joined #yocto
RobW has quit [Read error: Connection reset by peer]
lthadeus has joined #yocto
Minvera has joined #yocto
RobW has joined #yocto
Minvera has quit [Ping timeout: 260 seconds]
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
sotaoverride has quit [Ping timeout: 260 seconds]
sotaoverride has joined #yocto
alperak has joined #yocto
<alperak>
morning
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
jmd has joined #yocto
Chaser has joined #yocto
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #yocto
sotaoverride has quit [Ping timeout: 245 seconds]
sotaoverride has joined #yocto
Guest52 has joined #yocto
jmd has quit [Remote host closed the connection]
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
<Guest52>
Hello I have a question related to -march=nehalem compile flag. Trying to add own machine x86_64 core i7 and added require meta-intel/conf/machine/include/intel-corei7-64-common.inc to my machine.conf, this seems to be the source of the flag. How should I change it to haswell?
Chaser has quit [Quit: Chaser]
Chaser has joined #yocto
RobW has joined #yocto
Kubu_work has joined #yocto
alperak has quit [Quit: Client closed]
leon-anavi has joined #yocto
vladest has quit [Remote host closed the connection]
RobW has quit [Read error: Connection reset by peer]
mvlad has joined #yocto
Guest52 has quit [Quit: Client closed]
sotaoverride has quit [Ping timeout: 245 seconds]
sotaoverride has joined #yocto
dvergatal has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 255 seconds]
Vonter has joined #yocto
dvergatal has joined #yocto
samkent has joined #yocto
alperak has joined #yocto
rty has joined #yocto
<rty>
hi, people. when bitbaking a recipe, by default you see a list of popular variables with their values, such as DISTRO or MACHINE. is it possible to add my custom variable to this always-printed list? note: I know bitbake -e exists, but that is not my use-case.
<samkent>
You can append BUILDCFG_VARS in your local.conf with additional variable names
<rty>
samkent: thank you :)
xmn has joined #yocto
Nonkel has joined #yocto
lthadeus has quit [Ping timeout: 245 seconds]
sakman has quit [Ping timeout: 245 seconds]
khem has quit [Quit: Connection closed for inactivity]
vladest has joined #yocto
lthadeus has joined #yocto
dvergatal has quit [Quit: leaving]
xmn has quit [Ping timeout: 240 seconds]
<lthadeus>
Happy Holidays Guys! Stay Warm & Safe!
lthadeus has quit [Quit: Leaving]
Chaser_ has joined #yocto
Chaser has quit [Ping timeout: 256 seconds]
dvergatal has joined #yocto
sakman has joined #yocto
prabhakarlad has joined #yocto
<dvergatal>
is it possible to somehow override bitbake's bb module without overwritting it?
Chaser_ has quit [Remote host closed the connection]
Chaser has joined #yocto
Chaser_ has joined #yocto
Chaser has quit [Ping timeout: 260 seconds]
<LetoThe2nd>
yo dudX
* RP
notices what is probably a nasty performance issue in our core locking function
samkent has quit [Quit: Leaving]
RobW has joined #yocto
neofutur_ has quit [Ping timeout: 276 seconds]
neofutur_ has joined #yocto
Guest52 has joined #yocto
Guest52 has quit [Quit: Client closed]
sotaoverride has quit [Ping timeout: 252 seconds]
camus has quit [Remote host closed the connection]
sotaoverride has joined #yocto
goliath has joined #yocto
* LetoThe2nd
suggests rearringing it. Hm. "nasty locking issue in our permance core". Not better. "locking issue in our core nasty performance"? Also not better. Seems to be really problematic, then.
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
dvergatal has quit [Remote host closed the connection]
dvergatal has joined #yocto
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
Minvera has joined #yocto
RobW has quit [Read error: Connection reset by peer]
dvergatal has quit [Ping timeout: 255 seconds]
dvergatal has joined #yocto
samkent has joined #yocto
dvergatal has quit [Quit: leaving]
Chaser has joined #yocto
Chaser_ has quit [Ping timeout: 260 seconds]
Vonter has quit [Ping timeout: 268 seconds]
Vonter has joined #yocto
neofutur_ has quit [Ping timeout: 245 seconds]
<JPEW>
rburton: I feel dumb now :)
<rburton>
i poked around to see if there was an edge case with parse order somewhere
neofutur has joined #yocto
sotaoverride has quit [Ping timeout: 252 seconds]
sotaoverride has joined #yocto
RobW has joined #yocto
Chaser has quit [Quit: Chaser]
camus has joined #yocto
RobW has quit [Read error: Connection reset by peer]
dvergatal has joined #yocto
RobW has joined #yocto
khem has joined #yocto
dvergatal has quit [Ping timeout: 245 seconds]
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
lthadeus has joined #yocto
<JPEW>
rburton: Ya, I looked at the code and it clearly resolves weak assignment before append remove
<JPEW>
Not sure if it gets strange with deeper overrides though
<rburton>
JPEW: presumably this was a real problem for you somewhere though
<JPEW>
IDK why you would need it too though
Minvera has quit [Ping timeout: 245 seconds]
<JPEW>
Well, when you incorrectly do PACKAGECONFIG:pn-systemd:remove, yes
<rburton>
the use of override syntax for operations was in hindsight not ideal ;)
RobW has quit [Ping timeout: 246 seconds]
RobW has joined #yocto
<JPEW>
rburton: I think the thing that threw me was for packageconfig, you have to do `PACKAGECONFIG:remove:pn-systemd` and for RDEPENDS, you do `RDEPENDS:systemd:remove`
<JPEW>
Different context, and I can see why you would do each one in each place
samkent has quit [Ping timeout: 260 seconds]
* JPEW
idly wonders if one could write a QA warning for it
samkent has joined #yocto
<rburton>
yeah the syntax there isn't ideal
xmn has joined #yocto
jmd has joined #yocto
samkent has quit [Ping timeout: 245 seconds]
vladest has quit [Quit: vladest]
samkent has joined #yocto
flom84 has joined #yocto
xmn has quit [Quit: ZZZzzz…]
xmn has joined #yocto
Nonkel has quit [Ping timeout: 250 seconds]
flom84 has quit [Remote host closed the connection]
samkent has quit [Remote host closed the connection]
samkent has joined #yocto
samkent has quit [Quit: Leaving]
<arkanoid>
"ERROR: Execution of event handler 'defaulttoaster_buildhistory_dump' failed" on "bitbake core-image-minimal" on default x86 machine. Do you have any idea what this means?
rty has quit [Ping timeout: 250 seconds]
<arkanoid>
FileNotFoundError: [Errno 2] No such file or directory: '/mnt/ssd/yocto/poky/build/buildhistory/images/qemux86_64/glibc/core-image-minimal/installed-package-sizes.txt'
vladest has joined #yocto
gsalazar has joined #yocto
xmn has quit [Quit: ZZZzzz…]
lthadeus has quit [Remote host closed the connection]
sotaoverride has quit [Ping timeout: 240 seconds]
sotaoverride has joined #yocto
xmn has joined #yocto
RobW has quit [Ping timeout: 256 seconds]
vmeson has quit [Quit: Konversation terminated!]
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
dvergatal has joined #yocto
048AAHUGW has joined #yocto
dvergatal has quit [Ping timeout: 260 seconds]
leon-anavi has quit [Quit: Leaving]
<JPEW>
RP: Ok, I think I have the SPDX changes working; it's basically your previous change plus some changes in create-spdx-2.2.bbclass to make it all machine specific
<JPEW>
I'm going to run the sstate selftests locally just to make sure it's not going to break anything
gsalazar has quit [Ping timeout: 252 seconds]
xmn has quit [Quit: ZZZzzz…]
<arkanoid>
what is bitbake doing at "Initialising tasks: 44%" it gets there in seconds, then it stops there for minutes with 0% cpu and net usage
<JPEW>
arkanoid: Might be trying to contact the upstream hash equivalence server (and failing, or it's really slow)
<JPEW>
arkanoid: Check if BB_HASHSERVE_UPSTREAM is set
<JPEW>
arkanoid: Ya, see if you clear that out if it's faster
<arkanoid>
JPEW: clear or comment?
<JPEW>
either
xmn has joined #yocto
xmn has quit [Quit: ZZZzzz…]
<arkanoid>
it keeps hanging, now on "No currently running tasks (0 of 1) 0% |"
<arkanoid>
ctrl-c "Waiting for 0 running tasks to finish" :-/
<arkanoid>
feels like working with an alpha state system
Lihis has quit [Quit: Quitting]
otavio has joined #yocto
vladest has quit [Quit: vladest]
<JPEW>
arkanoid: If you don't have good connectivity to the upstream hashserver and sstate, it can cause some problems. You might try to also clear out SSTATE_MIRRORS and see if that helps
<khem>
I was looking at a ptest failure for cpio and something has changed such that chgrp -R ptest ... should change the group to ptest in do_install_ptest but in final rootfs it appears under group messagebus instead what could change this ?
<JPEW>
arkanoid: In particular, if you are on a corperate network with restricted connectivity. If it's still slow with those two variable cleared out, let us know
jmd has quit [Remote host closed the connection]
Lihis has joined #yocto
Lihis has quit [Quit: Quitting]
Lihis has joined #yocto
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
alperak has quit [Quit: Client closed]
RobW has quit [Read error: Connection reset by peer]
Kubu_work has quit [Quit: Leaving.]
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
Guest92 has joined #yocto
Vonter has quit [Ping timeout: 268 seconds]
Guest92 has quit [Client Quit]
Vonter has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
yudjinn has quit [Ping timeout: 255 seconds]
RobW has quit [Read error: Connection reset by peer]
yudjinn has joined #yocto
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
RobW has quit [Read error: Connection reset by peer]
RobW has joined #yocto
sotaoverride has quit [Ping timeout: 264 seconds]
sotaoverride has joined #yocto
<RP>
JPEW: sounds good although I am a little worried about the performance implications still :/
<RP>
khem: which package backend? Sounds like the gids are getting out of sync with the group names
<JPEW>
RP: Ya, still trying to resolve one more bug
<JPEW>
On the plus side, I fixed a bug in sstate. Drove me mad why SSTATE_MANMACH was in diffsigs :)
<JPEW>
(patch just sent)
<JPEW>
RP: Also.... stamp-extra-info is really kinda sstate-stamp-extra-info since it only affects sstate right?
<JPEW>
AFAICT
xmn has joined #yocto
<JPEW>
Ah, it goes into the stamp file name
RobW has quit [Read error: Connection reset by peer]
<RP>
JPEW: right, it changes STAMPS files
<RP>
JPEW: I saw the patch. I was wondering how things worked :/
<JPEW>
RP: In general, I don't think users noticed too much because that variable didn't change often, but I think it could trigger over-rebuilding in some cases
<JPEW>
Also.... another observation I've made is that do_recipe_qa and do_deploy_source_date_epoch depend on MACHINE via sstate code. This isn't _really_ too much of a problem, but it does mean rebuilds even though those tasks really arent machine specific
RobW has joined #yocto
<RP>
JPEW: that is an issue and we should fix that
<RP>
particularly for natives
<RP>
that might explain why the autobuilder is more heavily loaded
<JPEW>
Those ones in particular are problematic because they are so early in the dependency chain so it reruns fetch/pack/etc.
<JPEW>
Ya, I was thinking it might be
<RP>
definitely should be fixed
<RP>
and should probably have some tests adding
<JPEW>
Ya, I have a possible fix, but IDK if it's the right one, let me check quick
<JPEW>
my sandbox is a bit of a mess
<RP>
I know that feeling :/
<JPEW>
My dirty fix is `sstate_install[vardepsexclude] += "STAMP"` and `sstate_package[vardepsexclude] += "SSTATE_PKG"`; IDK if that's even a good idea though
<RP>
I would need to look more closely at that...
<JPEW>
Ya, I figured
<RP>
in theory those are ok...
<JPEW>
Right, I kinda figured you really need to have correct detecting in your task if it needs to rebuild for some reason; the destination file name changing _probably_ shouldn't be a factor?
<JPEW>
Well... maybe
<JPEW>
Might need an additional vardep on SSTATE_VERSION or something
<JPEW>
IOW, if that breaks something I'm 20% sure that the recipe had underspecified dependencies to begin with
<JPEW>
s/recipe/task/
<RP>
JPEW: right, I'd just have to think about it for a bit. If SSTATE_VERSION changes, it simply doesn't find the files at all :)
<RP>
(that was intentional)
<JPEW>
Ya, but maybe you'd want the tasks to run to write the new files even if nothing else changed (maybe that's unlikely though)
<RP>
hmm
* JPEW
does a build to get the exact dependencies
bantu has quit []
bantu has joined #yocto
<JPEW>
Ugh, I need to write this down because it's going to be over a week until I can look at it again once I'm done for today
<RP>
JPEW: oddly enough I'm sitting wondering what to do with my "context" :/
vladest has joined #yocto
dgriego has quit [Ping timeout: 256 seconds]
dgriego has joined #yocto
RobW has quit [Read error: Connection reset by peer]
dgriego_ has joined #yocto
dgriego has quit [Ping timeout: 256 seconds]
<JPEW>
Ya, you need both vardepexclude to excise MACHINE from the task
<RP>
JPEW: can we not just exclude MACHINE directly?
<JPEW>
RP: I just tried that, and it didn't seem to work
<JPEW>
It's burried very deep in the variable depenency tree
<JPEW>
Not sure if it's because these are python function instead of tasks, or what
<RP>
I know this can be hard to nail down...
<JPEW>
I can trace the MACHINE dependency in the signature just fine, but the things I've tried to just ignore MACHINE have failed; I had to ignore the specific variable being referenced in the python functions that (indirectly) dependended on MACHINE
<RP>
I'm too tired to be of much help atm I'm afraid
<JPEW>
RP: No worries, I'm pretty much done for the day as soon as I get my thoughts written down
RobW has joined #yocto
<RP>
JPEW: is this only if you make the spdx stamp machine specific
<RP>
?
<JPEW>
It uncovered the problem, but it's happening way before the SPDX tasks run
<JPEW>
I think the current test cases don't cover it
<RP>
JPEW: a local build doesn't seem to have this
<JPEW>
Well, what happens is that with your ABI safe change, so_create_spdx reruns because do_recipe_qa stamp changes in base-files (for example)
<JPEW>
(when the machine changes)
Minvera has joined #yocto
<JPEW>
Which... might be a problem, but it's really strange that do_recipe_qa is machine depenedent at all?
Minvera has quit [Remote host closed the connection]
RobW has quit [Read error: Connection reset by peer]
<RP>
JPEW: isn't base-files machine specific in the first place so this isn't an issue?
<JPEW>
Ah, yes it is
<JPEW>
Well that explains a lot I suppose
<RP>
I was assuming this was happening for a PACKAGE_ARCH recipe or a native one
xmn has quit [Quit: ZZZzzz…]
<JPEW>
Right, base-files triggers my woes because it's MACHINE_ARCH, but ABI safe :)
<RP>
that is understandable :/
<JPEW>
I've almost got it working though. The spdx task are machine tasks, but the sstate_sametune_samesigs test fails because.... well it doesn't realize they are machine specific
<JPEW>
(because they still live in the tune-arch stamps directory)
<RP>
I just worry that even if you fix the test, is the wider rebuilding going to be extremely problematic :/
<JPEW>
Ya, I'm not sure what to do about that; I was careful to make sure the SPDX tasks only depend on sstate tasks, so in theory, you shouldn't ever have to actually rebuild everything if your SPDX changes
<JPEW>
But probably a discussion for next year
<RP>
agreed
RobW has joined #yocto
<RP>
JPEW: crazy idea. We write the SPDX into an intermediate format, then just search and replace all the document links when writing out the final machine specific data
* RP
really needs to stop thinking
RobW has quit [Read error: Connection reset by peer]