qschulz has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
qschulz has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
akiCA has quit [Ping timeout: 256 seconds]
rber__ has joined #yocto
vladest has quit [Read error: Connection reset by peer]
rber|res has quit [Ping timeout: 246 seconds]
RobertBerger has quit [Ping timeout: 240 seconds]
vladest has joined #yocto
rber|res has joined #yocto
wCPO9 has joined #yocto
rber__ has quit [Remote host closed the connection]
risca has quit [Quit: No Ping reply in 180 seconds.]
vmeson has quit [Remote host closed the connection]
matthewcroughan has quit [Remote host closed the connection]
vmeson has joined #yocto
Shaun has quit [Ping timeout: 272 seconds]
rber__ has joined #yocto
matthewcroughan has joined #yocto
wCPO has quit [Read error: Connection reset by peer]
wCPO9 is now known as wCPO
risca has joined #yocto
lukma_ has joined #yocto
Shaun has joined #yocto
mcfrisk_ has joined #yocto
RobertBerger has joined #yocto
mcfrisk has quit [Ping timeout: 272 seconds]
lukma has quit [Ping timeout: 272 seconds]
mckoan|away has quit [Ping timeout: 272 seconds]
mischief has quit [Ping timeout: 272 seconds]
opello has quit [Ping timeout: 272 seconds]
matthewcroughan_ has joined #yocto
matthewcroughan has quit [Ping timeout: 272 seconds]
rber__ has quit [Ping timeout: 272 seconds]
LetoThe2nd has quit [Ping timeout: 272 seconds]
rfs613 has quit [Ping timeout: 272 seconds]
mckoan|away has joined #yocto
marc2 has quit [Remote host closed the connection]
rfs613 has joined #yocto
opello has joined #yocto
mischief has joined #yocto
marc2 has joined #yocto
LetoThe2nd has joined #yocto
jclsn has quit [Ping timeout: 250 seconds]
jclsn has joined #yocto
willo_ has joined #yocto
sakoman has quit [Quit: Leaving.]
<kp7299[m]>
<Saur[m]> "kp7299: The `master` branch of..." <- At that time I was trying to work in master branch of yocto project poky only, so that i could get those patches too which were present in the honister branch but were not in origin/master and now not even in master and thus in either of them I was unable to find those patches or I should clone OE repo and switch to it's master branch and work on curl ptest?
jclsn has quit [Ping timeout: 248 seconds]
<kp7299[m]>
And yeah, it was I guess 2am thus I hadnt responded after that although i was trying out those branches
jclsn has joined #yocto
jclsn7 has joined #yocto
jclsn has quit [Ping timeout: 276 seconds]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
jclsn7 has quit [Ping timeout: 256 seconds]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
jclsn7 has joined #yocto
sakoman has joined #yocto
troth has quit [Ping timeout: 276 seconds]
troth has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<kp7299[m]>
Presently, even in the oe-core github repo, I'm unable to get those curl patches even after switching to master and updating by git pull, because branch and git pull were only two options i knew for latest update, if there is some other alternate, do let me know
amitk has joined #yocto
mcfrisk_ has quit [Quit: leaving]
mcfrisk has joined #yocto
sakoman has quit [Quit: Leaving.]
olani has quit [Remote host closed the connection]
mvlad has joined #yocto
<khem>
rburton jonmason infact the hafnium issue is happening with prebuilt toolchain I see TOPDIR/build/tmp/work/qemuarm64-yoe-linux-musl/hafnium/2.6-r0/git/prebuilts/linux-x64/clang/lib64/clang/12.0.5/include/stdnoreturn.h:13:18: note: expanded from macro 'noreturn'
<khem>
so I wonder if hafnium works with musl or not
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<khem>
sent a patch to fix it
chep has quit [Ping timeout: 248 seconds]
chep has joined #yocto
kranzo has joined #yocto
RobertBerger has quit [Quit: Leaving]
rber|res has quit [Quit: Leaving]
rber|res has joined #yocto
leon-anavi has joined #yocto
fleg has quit [Remote host closed the connection]
TundraMan has joined #yocto
marka has quit [Ping timeout: 260 seconds]
<LetoThe2nd>
yo dudX
<jclsn7>
dobroje utro
jclsn7 is now known as jclsn
tomzy_0 has joined #yocto
goliath has joined #yocto
rfuentess has joined #yocto
<qschulz>
mornin' folks
<qschulz>
yudjinn[m]: you could use containers though if arch does not work good enough for you
<qschulz>
CROPS, pyrex, kas are three different techs
gsalazar has joined #yocto
beneth has joined #yocto
BhsTalel has joined #yocto
<BhsTalel>
Hello, what do you prefer busybox or coreutils , or can I integrate them both ? Because, Busybox only didn't give me commands like (ls, cat, ...)
<LetoThe2nd>
BhsTalel: you often have busybox plus a select number of full featured commands from coreutils. plus, busybox can be massively configured/customized
<paulg>
busybox can be configured to give you a large group of common commands - and should in default configurations provide "ls" and "cat"
<BhsTalel>
So, I can only use Busybox ?
<LetoThe2nd>
sure.
<paulg>
if you want - the primary frustration with that is with "regular unix users" - we expect specific behaviours and specific command switches.
<paulg>
the busybox versions typically only take a subset of switches, if any at all.
<BhsTalel>
Great, it is so clear now, thanks alot:) O:3
<paulg>
it may make sense to have busybox in your initramfs, where you don't expect to typically interact with it in a non-automated fashion, and then regular coreutils in your full rootfs - assuming your target has the space for it.
<LetoThe2nd>
as usual, it DEPENDS
<BhsTalel>
Yes, I use Busybox for initramfs
<BhsTalel>
Since Busybox has its own configuration and after finding out that statistics favors Busybox over coreutils, I think Busybox is the best choice
<LetoThe2nd>
BhsTalel: is this something that you are facing currently in your day to day work?
<BhsTalel>
I am maintaining a new BSP layer which has custom distros and images, and I am trying to select the default linux commands provider.
<LetoThe2nd>
BhsTalel: would you feel like sharing that experience at the yocto project summit? :-)
<paulg>
my two most important criteria I'd recommend you consider is 1) will people interact with it at a CLI level, and 2) do I have the flash/storage space for the larger footprint.
<LetoThe2nd>
this sounds like one of the topics that we "old dogs" often overlook and take as given, so a fresh view shared is much appreciated.
<BhsTalel>
I actually have something else to share, and I am thinking if it is good, I have slides that I usually present to my coworkers about "Full Kernel Support in Yocto" whcih presents the basics of the Linux kernel compilation and steps and the output files, after that I move to Yocto and how it emplements all of that including (out of tree modules
<BhsTalel>
recipes, device tree recipes, adding new kernel, kernel fragments, ...) and ending with some best practices
<BhsTalel>
Can this be suitable for the summit ?
<LetoThe2nd>
BhsTalel: of course!
Schlumpf has joined #yocto
<BhsTalel>
The slides are made using my companies powerpoint template, is that okay ? Or should I use another ?
xmn has quit [Ping timeout: 276 seconds]
<BhsTalel>
my company*
<LetoThe2nd>
BhsTalel: we are usually pretty relaxed about it if the content already exists.
<BhsTalel>
So I can use it as it is (Having the name of my company) ?
<LetoThe2nd>
BhsTalel: usually yes. We might add a generic bumper slide, but in the vast majority of cases it is no problem.
<BhsTalel>
Great news, how can I submit the slides ?
<BhsTalel>
Great, I will update the slides properly, and I will submit it.
<BhsTalel>
Thanks for giving me the courage , I was thinking about it but I am kinda stressed hhh
<qschulz>
BhsTalel: now that the conferences are online, it's less stressful to me because you're in an environment you know and you don't see hundreds of eyes directed to you :)
<qschulz>
so it's the right time!
<BhsTalel>
Yes, that is correct :]
<qschulz>
BhsTalel: the talk needs to be accepted first, so no need to start updating it now if it's not taken (if presenting to YP Summit is the only reason for updating it of course)
bps has joined #yocto
bps has joined #yocto
<BhsTalel>
I need to update it , because it has something related to a specific board example, the board is not open source, so I have to make it generic first
zeddii has quit [Ping timeout: 246 seconds]
zeddii has joined #yocto
risca has quit [Ping timeout: 246 seconds]
risca has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<RP>
qschulz: I updated the docs with some of your patches, hopefully things look better?
<RP>
qschulz: it did rebuild this time
<qschulz>
RP: did a quick check live, seems to be doing what we want
<qschulz>
thx :)
<RP>
qschulz: ok, good :)
<RP>
qschulz: I wasn't sure whether we needed to wait for michael to get back on the RFCs
<RP>
qschulz: I think I'll merge your rfcs as we should make the latest release the default
<RP>
ndec: agreed?
florian has joined #yocto
Tokamak has quit [Ping timeout: 250 seconds]
<qschulz>
RP: thinking about it, I'm not even sure the switchers.js worked before for named versions
<RP>
qschulz: I know I'd tried to but perhaps not :/
<BhsTalel>
Hello, I can help with writing documentation for Yocto. Just guide me where :]
<kp7299[m]>
Actually , Could anyone confirm me are the master branch of yocto and openembedded both, do both of them curl testsuites in curl folder, as I cant see them even I have switched to master branch and updated to via git pull master
Tokamak has joined #yocto
<qschulz>
RP: don't have an idea right now on how to fix the named versions
<qschulz>
RP: https://docs.yoctoproject.org/dunfell/ is ok because it's actually 3.1.15, but the switcher is broken because it relies on numbered versions to be used to replace the version by another one
<kp7299[m]>
RP: qschulz Just wanted to know are testsuites already being there inside yocto projects for each packages, if they are then where we can find them or with what extension or name they would be present?
<qschulz>
kp7299[m]: recipes are just fetching source code of other upstream projects
<qschulz>
the testsuites are in the source code of those projects
<qschulz>
so it is NOT available in any layer
<qschulz>
you need to have a look at the upstream project and check how they are running their testsuites and hook this up to ptest in Yocto
<qschulz>
at least that's my very basic understanding of the task
<kp7299[m]>
upstream project you meant by if curl is there then for curl which repo i need to check, just want to know about this upstream project , just let me know with any example
<kp7299[m]>
And one generalised thing which I know, that I require to see those test suites and try to reproduce those in the automation process, that is via these ptests, thats why I'm trying to find these testsuites
<kp7299[m]>
but regarding this upstream project, I'm unable to understand
<kp7299[m]>
* upstream project which you told qschulz , I'm
<qschulz>
curl has a testsuite apparently
<qschulz>
you need to check how this testsuite is run
<qschulz>
then this "how" you hook to ptest in Yocto
<qschulz>
with the patchset from 2016/2017 that rburton sent yesterday here, it could probably help you get started
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<qschulz>
I remember an explicit make target call somewhere in the patchset
bps has quit [Ping timeout: 276 seconds]
<qschulz>
some curl info can be found in the recipe
<qschulz>
at least all branches would be X.Y.999 now I think
<qschulz>
(if they are not on a tag directly)
<qschulz>
but the subpath in the URL is still not the same as the version
<RP>
qschulz: ah, so the issue is older releases
<qschulz>
RP: multiple issues sadly
<qschulz>
for one, hardknott returns 3.3.6 instead of 3.3.999
<qschulz>
second, named versions (subpath in the URL e.g. dunfell instead of 3.1.x) breaks the dropdown menu
<qschulz>
because it assumes the release from documentation_option is in the subpath
<qschulz>
(it's not, because release would be 3.3.999 for example, but the subpath would be hardknott)
<qschulz>
and third, honister is marked as obsolete (this one should be simple, just a check on whether 999 is in the version and then do not print the warning)
<RP>
paulg: it is because devshell uses fakeroot :(
<paulg>
yeah, I know why it happens. I'm wondering what is the right way to fix it.
<qschulz>
RP: ah you meant patches for the conf.py in older branches?
<RP>
qschulz: yes
<qschulz>
if so, then I'm not working on it
<qschulz>
I'm working on fixing the named releases
<paulg>
I wonder if we can give the devshell the gitconfig for "root" for the whole build dir, or if it has to be on a pkg-per-pkg basis?
bps has joined #yocto
bps has joined #yocto
<RP>
qschulz: I think those are ok though aren't they?
<RP>
paulg: not sure :/
<RP>
paulg: we could alias git to PSEUDO_UNLOAD=1 git
<RP>
which is evil but might just work
<paulg>
heh - I can confirm that works. I can't comment on how evil that is.
<qschulz>
RP: I'll probably do a PoC for the suggestion but was wondering if we couldn't move the migration pages to the transition branch. That way, the references to bitbake docs would point to the correct link (and not need to be updated in case the reference disappears)
<RP>
qschulz: that is worth thinking about
<paulg>
RP, actually that probably isn't so evil at all...
<RP>
paulg: except files that are created won't be tracked by pseudo so you have the opportunity to mess up pseudo's state if you do "bad" things
<RP>
paulg: I'm not sure we care
<paulg>
I was thinking - in that you can write commit logs that don't look like "root@..." -- use git send-email and have it source your SMTP settings from $HOME etc.
wybpip[m] has joined #yocto
wybpip[m] has left #yocto [#yocto]
<RP>
paulg: that argument works
<paulg>
I usually use devshell 'cause it is shorter to type than finding the tmp/work/foo/bar/board/baz/version path manually with tab completion
<RP>
paulg: a kernel dev using a helper environment from a build system?!
<RP>
I guess it is at least terminal based
<paulg>
well, if I want to test crap with the actual compiler we've built, devshell is still largely the easiest.
* paulg
tries to ignore the implicit scorn cast on kernel devs ;-)
<RP>
paulg: I'm just teasing :)
<paulg>
I know. I'd do the same. :-P
* RP
is listed in the kernel maintainers file so I can't exactly talk
<paulg>
I removed my entry. :-)
<paulg>
so now I'm forwarding all my kernel questions to you!
* RP
is struggling to understand why his build server is on a totally different IP block than the one he thought it was on
* RP
was surprised to get "network unreachable" errors
* RP
even wrote this into a config file so I must have intended it at some point
<paulg>
always fun when you leave booby-traps behind for yourself.
<paulg>
"I'll just change this now temporarily so I can test <blahblah>."
florian_kc has joined #yocto
<kp7299[m]>
<qschulz> "the version we use in master..." <- How to get this version number of a branch which is being cloned to my system, I checked for git describe command, but I dont find it relevant after result I got
<kp7299[m]>
qschulz: But I wanted to check for the present release which I have on my machine, because I was unable to see all patches in curl folder which were there in hinisyter but not in mastter
tomzy_0 has joined #yocto
<kp7299[m]>
So in that context also, I just wanted to know that if there is some other command too for checking version of present branch
shivamurthy has quit [Quit: Connection closed for inactivity]
<qschulz>
kp7299[m]: I assume curl got updated since honister and thus the patches were not needed anymore
<kp7299[m]>
ok, and each ptest-runner i can see the developer has written cd tests, I was trying to figure out where that tests folder reside for that particular testsuite, so in this context , I was checking whole things
GNUmoon has quit [Remote host closed the connection]
<kp7299[m]>
<qschulz> "you can also access the sources..." <- But would these let me know about those testsuites?
<RP>
qschulz: patches sent, see what you think. I can't easily carry these locally :/
<kp7299[m]>
<qschulz> "you can also access the sources..." <- For what purpose, do i need to do this?
<RP>
qschulz: sent a couple of review comments, just so you know I pay attention :)
<RP>
qschulz: I wasn't going to sent the comment on 1/3 until I noticed something on 3/3 which I think may need tweaking
<qschulz>
RP: hehe thanks :)
<qschulz>
I'll send new versions and review your patches later, got a vet appointment soon
<qschulz>
ping me if I haven't said anything by tomorrow
<RP>
qschulz: ok, I can't really hold mine locally the way I have them so I'll figure something out
<RP>
(there is a big risk I push something by accident given my scripts)
<qschulz>
RP: it's alright, we have them on the mailing list, that's enough for me :)
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
mckoan|away is now known as mckoan
ptsneves has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
<ptsneves>
Hey guys. I wonder if you could help me figure out what i am missing in the docs that might explain the behavior:
<ptsneves>
Imagine i have packages called ${PN}-healthcheck and it contains systemd services. Why d.getVar works for SYSTEMD_SERVICE_${PN}-healthcheck_class-devel_append but not for SYSTEMD_SERVICE_append_class-devel_${PN}-healthcheck?
nemik has joined #yocto
<rburton>
because append is special and that's not how variables work
<ptsneves>
so append should always come at the end?
<qschulz>
ptsneves: the order of overrides matters
troth has joined #yocto
<ptsneves>
qschulz thanks! I am looking at it! I found that it does not, if you do not consider an append an override as in defined in OVERRIDES. Can you clarify?
<rburton>
ptsneves: append and remove go first. OVERRIDES is the list of extra overrides, append and remove are override operators
<qschulz>
ptsneves: the issue here I believe is that Bitbake expects a SYSTEMD_SERVICE_${PN}-healthcheck variable
<qschulz>
so ${PN}-healthceck is technically not an override
<RP>
qschulz: it is when it is in OVERRIDES
<qschulz>
(I'm not entirely sure but I believe package names are not overrides?)
<RP>
qschulz: we do put the package name into OVERRIDES in some pieces of code
<qschulz>
RP: systemd.bbclass looks for SYSTEMD_SERVICE:${PN}-healthcheck though?
<qschulz>
RP: ack, thanks for clarification
<RP>
qschulz: right, that is a piece of code where it isn't in OVERRIDES
<kp7299[m]>
A small question , would this be right way to add multiple EXTRA_IMAGE_FEATURES in build, as presently , I just directly want to try for any one target for ptests then would go ahead with curl to implement for it, just trying to figure out flow in whole project...
<ptsneves>
RP so this means that the code where d.getVar(SYSTEMD_SERVICE_ + pkg) will be interpreted as a literal, due to the pkg not being in overrides. As it is a literal, the _append would be interpreted as being part of the package name, and d.getVar would fail to find such a variable. Is this interpretation correct?
<RP>
ptsneves: SYSTEMD_SERVICE_append_class-devel_${PN}-healthcheck means the SYSTEMD_SERVICE is appended with the value when the overrides class-devel and ${PN}-healthcheck are active
<RP>
ptsneves: the variable "SYSTEMD_SERVICE_ + pkg" is never set in that case
<RP>
SYSTEMD_SERVICE_${PN}-healthcheck_class-devel_append on the other hand means SYSTEMD_SERVICE_${PN}-healthcheck_class-devel is appeneded to if neither are in OVERRIDES, SYSTEMD_SERVICE_${PN}-healthcheck is appended to if class-devel is in OVERRIDES and SYSTEMD_SERVICE is appended to if both are in overrides
<rburton>
kp7299[m]: space separated list, so = "debug-tweaks ptest-pkgs"
<RP>
paulg: did you have a patch for the devshell fix?
<kp7299[m]>
rburton: ok
<paulg>
RP, I can if you think the idea won't break other use cases.
<RP>
paulg: git is totally broken now so I think it can only improve it
<paulg>
of course I've no idea where the devshell env is set up, so I hope you aren;t in a rush... some grepping is in order for a kernel-centric gomer like me.
<RP>
paulg: I wonder what disaster that statement will now induce :)
<kp7299[m]>
And I seriously dont know, till yesterday everything was going good, else I'm just suspicious about branch changes which i had made since yesterday, And I saw these things, but dont know what exact reason is for these variable change:
<RP>
paulg: we setup the environment in meta/classes/devshell.bbclass but I don't know whether we can create the alias from the environment?
<paulg>
ya just readin that file now
<ptsneves>
RP got it. I just had a look at the OVERRIDES output of '-e -c package' and indeed, ${PN}-healthcheck or any ${PN}* for that matter, are not in OVERRIDES. Thus this explains my situation. Only class-devel was set for my case. Thank you
<ptsneves>
by the way in bitbake/lib/bb/tests/parse.py@master there is an overwritten(dupplicated) "test_parse_overrides". If i understand correctly the first definition will not be ran. Is this understanding correct?
<RP>
ptsneves: correct, that is a bug
<paulg>
RP, here is a thought. Assuming we'll see more similar issues ... we could have a devshell path (with suitable wrappers) put in front of the "normal" path. Not sure if that makes things any easier than an "alias" approach...
<RP>
paulg: that is another way to solve it, yes. We do have a few directories like that in scripts/ already
<derRichard>
can i disable fakeroot for a target? i don't want that do_install of my recipe runs unter fakeroot.
<RP>
derRichard: I suspect there is code setting that in anon python
<RP>
derRichard: be warned that things will break though
<RP>
ptsneves: I've sent a patch for it
<derRichard>
rburton: long story short, the application runs git while building (and install target) and recent git is broken under fakeroot: https://marc.info/?l=git&m=164989570902912&w=2
<derRichard>
i need to unbreak the build pipeline ;-\
<rburton>
set PSEUDO_DISABLE=1 before invoking the bit that runs git
<RP>
derRichard: use the wrapper approach I'm talking with paulg about
<ptsneves>
RP thanks! I was looking at some of the tests, as they actually touch the situations we talked about
<rburton>
RP: yeah that :)
<RP>
ptsneves: someone copy and pasted a test badly, may have been me, didn't check
* paulg
chuckles
<kp7299[m]>
<qschulz> "you can also access the sources..." <- I got your point for this, you just wanted to say about bitbake <target> right? But presently I'm just seeking for testsuites and ptest nothing else
<derRichard>
PSEUDO_DISABLED or PSEUDO_UNLOAD looks also good
<kp7299[m]>
> <@qschulz:libera.chat> you can also access the sources from your Yocto build after you run bitbake curl or bitbake curl-native
<kp7299[m]>
* I got your point for this, you just wanted to say about bitbake \<target> right? But presently I'm just seeking for testsuites and ptest nothing else, might be that's why I was unable to get context
PaowZ has joined #yocto
selff has joined #yocto
GNUmoon has joined #yocto
ptsneves23 has joined #yocto
ptsneves has quit [Ping timeout: 250 seconds]
<derRichard>
rburton: RP: FYI, in my case the least invasive fix was adding PSEUDO_DISABLED=1 before calling git in our build script
<selff>
someone here told me to build opencv in yocto runtime. i tried but no change.
<rburton>
selff: all i can say is run profiling tools and see what the diffeernces are
<ptsneves23>
selff "cool" problem. Yep you need to profile. Also can it be that there is some hardware acceleration kernel module not installed in the yocto side?
xmn has joined #yocto
tgamblin_ has joined #yocto
tgamblin has quit [Read error: Connection reset by peer]
<qschulz>
rburton: how long does it take for patches to appear there?
<qschulz>
the ones sent today aren't there
<qschulz>
same on lore.kernel.org
<selff>
rburton ptsneves23 i did sysbench both raspbian and yocto.cpu, memory seem normal, but there is a difference in thread tests.Does this prove anything?
sakoman has joined #yocto
<ptsneves23>
nope. When talking about benchmarching i was meaning running a profiler on the binary itself. Like with gprof if using the GCC toolchain. Even so, before that I would check the driver for the TPU. Can you compare lsmod output in yocto vs raspbian?
<selff>
sure, i can
<rburton>
perf will be able to tell you if something is taking a lot more CPU
<rburton>
maybe meta-rpi is missing some hardware enabling that nobody has noticed, or raspian has some closed source blobs that are not in meta-rpi
<selff>
there are different things when i do lsmod. but i dont know how to compare. what exactly should i look for?
BhsTalel has quit [Ping timeout: 250 seconds]
hcg has joined #yocto
<selff>
ptsneves23 i forgot to tag you.
<RP>
sakoman: that kirkstone patchset looks quite heavy? :/
<sakoman>
RP: are there any in particular you are concerned with?
<sakoman>
RP: I went back and forth on the zlib one, but decided to see what people thought
<ptsneves23>
can you sort and provide a diff to a pastebin?
<sakoman>
RP: The other upgrades are all security/bug fixes and I added change logs to the commit messages where they were missing
<RP>
sakoman: rburton deliberately didn't send the zlib one for kirkstone, I could have merged differently :/
<RP>
sakoman: I guess I was thinking bug fixes would be on request rather than those upgrades but I guess see what others think
<sakoman>
RP: OK, I can drop that one!
<RP>
sakoman: see what others think, I was just a bit surprised
<RP>
sakoman: makes you wonder if we shouldn't scrap rc3 given the large list
<sakoman>
RP: Maybe I set my filter a little too low!
<RP>
sakoman: makes me feel I'm getting the release wrong
<selff>
@pt
<selff>
ptsneves23 i didnt quite understand what you mean. im new to the software world :D
<qschulz>
selff: lsmod | sort and copy-paste on a pastebin (a website where one can save plain text)
<sakoman>
RP: Nah, I don't think you got the release wrong. The bug/security fixes keep rolling in no matter what our release schedule is!
<ptsneves23>
qschulz exactly. Thank you :)
<sakoman>
RP: that's why we need a maintainer post release!
nemik has quit [Ping timeout: 240 seconds]
<rburton>
i saw libinput had a new CVE this morning, always something new...
<ptsneves23>
in yocto do you have the max frequency setting software?
<qschulz>
RP: mmmm... I do not understand why documentation_options.js has a dev version for the default version... it should be 3.4.3
<qschulz>
(to be clear, I do not reproduce locally...)
<selff>
ptsneves23 i check there. i tried with libedgetpu1-std which is working on rpi4(raspbian) and getting 20-22fps. on the yocto side, i get 11-13 fps with libedgetpu1-std.
<selff>
when i tried max frequency on yocto side, only 3-4 fps increased.
<ptsneves23>
ok then i am out of my depth. My apologies. I need to leave. Good luck and try the profiling.
<selff>
ptsneves23 ty so much. have a nice day.
<rburton>
selff: run the benckmark under perf, compare the profile
<rburton>
would be nice if rpi cared enough to actually maintain meta-rpi, but they don't
ptsneves23 has quit [Ping timeout: 250 seconds]
kranzo has quit [Quit: Client closed]
BCMM has joined #yocto
<selff>
rburton okay i wil try and let you know when i finish. i googled perf. is it performance counters for linux right? i earn something new from you every time i come here, so i want to say thank you.
troth has joined #yocto
<selff>
learn*
<rburton>
yeah, it's a tool to get performance data
<Saur[m]>
Is there any way to get bitbake to help identify what is causing `ERROR: When reparsing foo.bb:do_install, the basehash value changed from X to Y. The metadata is not deterministic and this needs to be fixed.`? The suggested `-Snone` and `-Sprintdiff` aren't very helpful... :(
<Tartarus>
if you aren't editing and saving the file while it's being parsed/used, the next thing is to see what variables you're using inside of do_install
<Tartarus>
Something in there keeps changing
<JaMa>
Saur[m]: I usually run -S none multiple times, save the sigdata files (like scripts/sstate-diff-machines.sh does) and then compare what changed between the runs
<smurray>
I’ve seen recipes manually sticking timestamps in variables cause it a couple of times
<T_UNIX[m]>
Hi
<LetoThe2nd>
smurray: yeah
<qschulz>
typically DATETIME
<qschulz>
T_UNIX[m]: howdy
<LetoThe2nd>
Saur[m]: i think i got the final hint by bitbake-diffsigs last time
<T_UNIX[m]>
I'm a bit confused. An image I've generated contains `/bin/sh`, while the sysroot inside the sdk I generated for this image (i.e. `bitbake $image -c populate_sdk`) does _not_ provide said shell.
<qschulz>
RP: If I didn't introduce one more regression, pretty happy with what we did today. Still don't understand why release is dev in documentation.js for the default branch on docs.yoctoproject.org. Next step will be to make a switchers.js for Bitbake
<Saur[m]>
JaMa: Hmm, there does not seem to be any differences if I run with `-Snone` multiple times. It just reports the same task hashes as mismatches over and over.
<qschulz>
which explains which distros are supported and which packages need to be installed on your host distribution
<kp7299[m]>
I had earlier already done with bitbake core-image-minimal
<kp7299[m]>
And that time there no errors and even have written just one recipe where yesterday i was facing issue, so basic steps i had done and those only i was following for this
<kp7299[m]>
Thats why I was feeling why such a red zonned screen
GLumen has joined #yocto
bps has quit [Ping timeout: 260 seconds]
<selff>
rburton i installed perf but i dont know what to test specifically. which command should i use? one of them record because of recording the profile into perf.data. is there anything you suggest i add?
<qschulz>
kp7299[m]: I assume you had a network blip at one point
<qschulz>
however the missing files is surprising
<qschulz>
kp7299[m]: can you simply remove tmp/work and tmp/work-shared and restart bitbake?
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<kp7299[m]>
<qschulz> "kp7299: can you simply remove..." <- Alright, I'll do so, Although I feel there shouldnt be any network issues, like it wont be ever possible to have network issue on those machines
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<rburton>
selff: google has lots of guides to using perf to get profiles
<selff>
rburton i think i asked wrong. i just wanted to ask if you have anything specific to recommend. im doing it by looking at google right now.
<rburton>
selff: no idea. just get profiles for both and see what the differences are.
<selff>
rburton thank youuu
falk0n[m] has quit [Quit: You have been kicked for being idle]
<kp7299[m]>
Earlier there were 17 errors for bitbake curl, now there are 16 , still unable to get why these are there for curl: https://pastebin.com/WdwCgC0r qschulz
<kp7299[m]>
I have deleted tmp and then again did bitbake curl
manuel1985 has quit [Quit: Leaving]
mckoan is now known as mckoan|away
vvn has quit [Ping timeout: 256 seconds]
<rburton>
kp7299[m]: the path starts "home/" so you're missing a leading / somewhere
Schlumpf has quit [Quit: Client closed]
vvn has joined #yocto
vvn has quit [Client Quit]
<rburton>
when you find out what you missed, sending a patch to sanity check that would be really helpful
vvn has joined #yocto
<kp7299[m]>
Presently this is on honister branch, then would it go as patch?
<kp7299[m]>
Because on master branch I just got those variable change errors, So I have build all this on another system but this time branch I hadnt switched to master
<kp7299[m]>
<rburton> "when you find out what you..." <- It worked
<kp7299[m]>
But now thing is it is on honister branch not on master branch and I got those variable change errors when I had switched to master branch: https://pastebin.com/7bTvJweQ rburton
rfuentess has quit [Remote host closed the connection]
<rburton>
kp7299[m]: re-run oe-init-build-env
<rburton>
you'll most likely need to use a new terminal for that
gsalazar has quit [Ping timeout: 276 seconds]
<khem>
rburton: the hafnium issue is perhaps seen by me because I am enabling ptest
<BhsTalel>
Hello, I am trying to start a shell on initramfs image bundled in the kernel image, but I got error:
<BhsTalel>
[ 2.439980] Run /init as init process
<BhsTalel>
[ 2.443665] Failed to execute /init (error -13)
<BhsTalel>
...
<BhsTalel>
[ 2.465728] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
<BhsTalel>
[ 2.473398] CPU: 0 PID: 1 Comm: sh Not tainted 5.4.24-2.1.0+g40df4fb3e #1
<BhsTalel>
Here is the content of my /init:
<BhsTalel>
#!/bin/busybox sh
<BhsTalel>
PATH=/sbin:/bin:/usr/sbin:/usr/bin
<BhsTalel>
mkdir -p /proc
<BhsTalel>
mount -t proc proc /proc
<BhsTalel>
mkdir -p /dev
<BhsTalel>
do_mknod /dev/console c 5 1
<BhsTalel>
do_mknod /dev/null c 1 3
<BhsTalel>
do_mknod /dev/zero c 1 5
<BhsTalel>
exec sh
<BhsTalel>
I think the problem is in (init) but I am not figuring it out.
<BhsTalel>
do_mknod() {
<BhsTalel>
test -e "$1" || mknod "$1" "$2" "$3" "$4"
<BhsTalel>
}
tomzy_0 has quit [Quit: Client closed]
amitk has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
BhsTalel has quit [Ping timeout: 250 seconds]
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
Mike23 has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
bps has quit [Remote host closed the connection]
bps has joined #yocto
bps has joined #yocto
Mike23 has quit [Quit: Client closed]
mvlad has quit [Remote host closed the connection]
tgamblin_ has quit [Quit: Leaving]
troth has quit [Ping timeout: 240 seconds]
troth has joined #yocto
doot322feed has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
<T_UNIX[m]>
what is one supposed to do to add a `/bin/sh` provider (package) to the SDK's sysroot? Adding i.e. busybox to the image for which the sdk is populated seems to be unsufficient.
nemik has joined #yocto
<khem>
T_UNIX do you intend it for target or sdk host
Minvera has quit [Remote host closed the connection]
<amahnui[m]>
``` ```
doot322feed has quit [Ping timeout: 250 seconds]
rsalveti has quit [Quit: Connection closed for inactivity]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<vvn>
Can systemd-machine-units be appended with custom scripts for the service files too or is it purely intended for unit files only?
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
goliath has quit [Quit: SIGSEGV]
amahnui has joined #yocto
akiCA has quit [Ping timeout: 250 seconds]
leon-anavi has quit [Quit: Leaving]
florian_kc has quit [Ping timeout: 276 seconds]
<reatmon>
Is there something going on the the Yocto project Patchwork server? We keep seeing patches that are sent to our mailing list that take a really long time to show up in the database..