qschulz has quit [Read error: Connection reset by peer]
qschulz has joined #yocto
sakoman has quit [Quit: Leaving.]
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 268 seconds]
seninha has quit [Remote host closed the connection]
otavio_ has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
otavio has joined #yocto
sakoman has joined #yocto
jmiehe1 has joined #yocto
jmiehe has quit [Ping timeout: 268 seconds]
jmiehe1 is now known as jmiehe
Patrick60 has joined #yocto
amitk has joined #yocto
sakoman has quit [Quit: Leaving.]
thomasd13 has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
Adrian_ has joined #yocto
<wyre>
hi guys, I've got this append https://bpa.st/62BQ for the kernel recipe I need to provide to the machine I'm building my image for but my question is ... how may I control if the 0002-modify-crit-temp.patch is included in the image or not? I'd like just to include this patch for a dev image, not the production one.
<wyre>
I mean ... the problem is though I make a custom machine ... I will need also to use the linux-engicam kernel
<wyre>
should I copy the entire linux-engicam recipe into a whole custom recipe for the kernel called in another way?
jmiehe has quit [Ping timeout: 268 seconds]
<wyre>
the point is I'd like to include the patch depending on the image, nor the machine, because if I create a different machine both will use the very same source code for the kernel, but not the patches.
wkawka has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
sanderz has joined #yocto
<sanderz>
I'm trying to build a vendor kernel supplied as part of a buildroot set of files. I put the kernel directory into my own git repo and then updated the vendor's kernel recipe to pull that down (instead of the original vendor kernel). I keep getting a few '| fatal: not a git repository (or any of the parent directories): .git' errors - I am probably
<sanderz>
doing something incredible naive but if anyone could point to how I could debug this that would be appreciated.
mvlad has joined #yocto
<sanderz>
To be clear, that error occurs during the 'do_compile' stage, around here:
<sanderz>
| fatal: not a git repository (or any of the parent directories): .git
<sanderz>
| GEN .version
<sanderz>
| CHK include/generated/compile.h
<sanderz>
| LD vmlinux.o
zpfvo has joined #yocto
frieder has joined #yocto
<wkawka>
Hi, what exit code 137 means in do_package_write_rpm taks?
ptsneves has joined #yocto
GillesM has joined #yocto
Patrick60 has quit [Quit: Client closed]
dev1990 has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
leon-anavi has joined #yocto
prabhakarlad has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
kanavin has quit [Quit: Leaving]
florian has joined #yocto
kanavin has joined #yocto
<qschulz>
wyre: proper way is to have either a development distribution or a development machine
<qschulz>
wyre: other options are to have two device trees and have the bootloader pick the correct one before booting Linux (or use a device tree overlay)
<qschulz>
or to modify the device tree directly from the image recipe in the rootfs directly
<qschulz>
but you very likely want a distribution because the "I only want this for the development image" scope will grow over time and there'll be a point where doing anything without a different distribution will be a LOT of pain, maybe even near impossible to do
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
<qschulz>
sanderz: Hehehe, this very much seems like a bad vendor kernel you got there
<qschulz>
you probably have some git commands in the kernel Makefile
<qschulz>
I had this once with Amlogic kernels running some git command on build
ardo has quit [Read error: Connection reset by peer]
<sanderz>
qschulz Yeah this is between two Rockchip kernels and your comment confirms my suspicions.
ardo has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<sanderz>
qschulz Thank you.
prabhakarlad has joined #yocto
florian_kc has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
xmn has quit [Ping timeout: 255 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
xmn has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
sanderz has quit [Ping timeout: 252 seconds]
ptsneves has joined #yocto
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
Adrian_ has quit [Ping timeout: 268 seconds]
argonautx has joined #yocto
GillesM has quit [Quit: Leaving]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
ptsneves has quit [Quit: ptsneves]
ptsneves has joined #yocto
<T_UNIX[m]>
hi
<T_UNIX[m]>
is there some kind of filter/whatever to tell bitbake to retry if the build failed tue to segfault or some compiler error?
<LetoThe2nd>
yo dudX
<LetoThe2nd>
T_UNIX[m]: in the hope that.... the build magically works the second time? (hint: the answer is "no")
vladest has quit [Quit: vladest]
vladest has joined #yocto
<T_UNIX[m]>
LetoThe2nd: I guess it depends on the error. I'm talking about insufficcient resources and insufficient handling, that leads to SEGV or an internal compiler error. This depends on the amount of resources available at a single point. Now usually I'm using x tasks in parallel. Depending on just which these tasks are, that are executed in parallel the available memory is not enough.
<LetoThe2nd>
T_UNIX[m]: you are shortcutting a number of things here. first and foremost, bitbake doesn't know *why* a build fails. the executable returns a non-null state, and thats it. second, if your setup suffers such "transient" errors, then the key is to fix the setup - not introduce band aids that essentially go like "try as often as you want until you get a lucky punch"
ptsneves has quit [Read error: Connection reset by peer]
ptsneves1 has joined #yocto
<T_UNIX[m]>
<LetoThe2nd> "T_UNIX: you are shortcutting a..." <- Sure, understood. This would just be a lazy workaround, for my travel machine. Bitbake does not know about this kind of error OTB. But, if I can read these errors from the log, so could a filter tool.
ptsneves1 is now known as ptsneves
<LetoThe2nd>
T_UNIX[m]: if at all, then it would rather make sense to find some means of adjusting parallelisation/resource usage.
seninha has joined #yocto
ptsneves1 has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
davidinux has quit [Ping timeout: 268 seconds]
ptsneves1 has quit [Read error: Connection reset by peer]
ptsneves has joined #yocto
davidinux has joined #yocto
ptsneves has quit [Read error: Connection reset by peer]
ptsneves1 has joined #yocto
ptsneves1 has quit [Client Quit]
ptsneves has joined #yocto
<T_UNIX[m]>
<LetoThe2nd> "T_UNIX: if at all, then it would..." <- that would be the "more right" thing to do, I assume.
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
<vmeson>
T_UNIX[m]: could try using the /proc/pressure limits we added in master recently and let me know if that helps? BB_PRESSURE_MAX_CPU = "500" in your local.conf?
<wyre>
qschulz, sure, my point is not as how to handle different kernels as how to handle different kernel patches
<wyre>
I mean ... the kernel is the same and currently I'm using a bbappend recipe
<vmeson>
LetoThe2nd: bitbake's theme song!
<wyre>
but not sure if I should just create a different kernel recipe in the machine dev case, for example
<LetoThe2nd>
vmeson: +1
Adrian_ has joined #yocto
<jclsn[m]>
I have an issue where SRC_URI:append = "git://git@some.gitlab.repo.git" doesn't get appended. How to debug this? I have tried -D, but that kind of overwhelmed me
<jclsn[m]>
Well SRC_URI:append = " git:/..."
<jclsn[m]>
Didn't forget the space
<LetoThe2nd>
jclsn[m]: usual first try: bitbake-getvar
<jclsn[m]>
Everything else gets appended, just not the Gitlab link
<jclsn[m]>
Yeah I did
<jclsn[m]>
It says it gets appended, but doesn't land in the final string
<qschulz>
wyre: the source code is not the same if you need a patch in one case and not the other
<LetoThe2nd>
jclsn[m]: what happens if you place something else at the very same instance of appending.
<qschulz>
wyre: you also don't need a different recipe if you use two machines
<qschulz>
you can just add SRC_URI:append:machine2 = " file://machine2.patch" to your kernel recipe then
<jclsn[m]>
What is in question is the ${CST_CERTS}, which contains the Gitlab link
<wyre>
qschulz, well, but I need to patch the very same source code in both cases
<LetoThe2nd>
jclsn[m]: AIUI the externalsrce effectively kills everything else.
<jclsn[m]>
LetoThe2nd: Why? Can you link a doc entry?
<jclsn[m]>
Currently studying the bitbake docu again anyway
<LetoThe2nd>
jclsn[m]: i cannot, thats just my guess/impression. what happens if you disable that?
<jclsn[m]>
LetoThe2nd: It is not part of my append file, so I guess in the original imx-boot recipe
<jclsn[m]>
Let me see
<LetoThe2nd>
jclsn[m]: in your workspace, that suggest you did something with devtool
<jclsn[m]>
Ah let me reset
<T_UNIX[m]>
<vmeson> "T_UNIX: could try using the /..." <- I assume the bottleneck is the available memory. But thanks for pointing this out.
<qschulz>
T_UNIX[m]: BB_PRESSURE_MAX_MEMORY then
<qschulz>
T_UNIX[m]: you can also limit the number of threads used by Bitbake
<wyre>
qschulz, so you mean I may add SRC_URI:append:machineX in the linux-engicam_%.bbappend recipe and then create two separate machine conf files containing essentially the same but being named differently?
<qschulz>
wyre: that, or a new distro conf file but yes
<T_UNIX[m]>
<qschulz> "T_UNIX: BB_PRESSURE_MAX_MEMORY..." <- when was this introduced? I cannot find any docs on it. I assume it's dynamically generated?
<perdmann>
Hi, is there any simple way to save the kernel error before my device gets a reset? Some kind of "Errormemory" I have disabled persistent logs to prevent SDcard damage
<qschulz>
T_UNIX[m]: docs patches are pending, added very recently to amster
<wyre>
I think it was because of the leading space
<wyre>
so it was looking ro a file called ....pathfile
<qschulz>
wyre: yup it was the missing leading space
<wyre>
sorry <name>.patchfile
<qschulz>
yup
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
<wyre>
nice, qschulz thank you 😊 but ... still not sure about what's causing a problem I've been having since some time ... I have to rerun bitbake to get it working, because the first time it's not able to patch the dts ... 😞 https://bpa.st/JCSA
<wyre>
not sure if I have to redo the patch ... 🤔 because I can read "Patch needs to be refreshed."
<qschulz>
wyre: re-running bitbake shouldn't fix the issue so I'm surprised
<qschulz>
you should probably rebase your patch on the proper kernel version
<qschulz>
I would suggest to remove the SRC_URI:append:whatever temporarily and then use devtool modify virtual/kernel to modify the sources, then create the patch and replace the one you have in your layer
<qschulz>
(don't forget to devtool reset when finished)
brazuca has joined #yocto
* RP
has an interesting bitbake patch for class scope issues. I suddenly realised how we could implement it
marc1 has joined #yocto
sakoman has joined #yocto
<qschulz>
RP: could some class actually belong to both recipe and global scopes? would such a thing make sense?
<JPEW>
RP: Ah, that's actually quite simple
<JPEW>
qschulz: I believe that would just be a "global" class?
<RP>
JPEW: hopefully simple but effective
<qschulz>
RP: oof to the docs changes though :p
<RP>
qschulz: an opportunity to clarify the scope of classes ;-)
<qschulz>
JPEW: I don't think it's a good idea to have a class that can be both inherit in the global and recipe scope to be in classes-global
<qschulz>
that would be a bit confusing (at least it is to me, but that might be the 4h of sleep talking right now)
<qschulz>
RP: yup!
<JPEW>
qschulz: No.... I meant I don't know why you have a class that did that. It seems like that's just a "global" class and there would be no reason include it in a recipe also
<RP>
qschulz: you couldn't put it in classes-global and have it work in recipe scope
<JPEW>
(but I might be misunderstanding some use case also)
<RP>
JPEW: some classes do work in both today but really were designed to be used one way only
<qschulz>
JPEW: no particular example to give, just trying to see if this is a possible scenario, and if so, how are we supposed to handle it
<qschulz>
RP: on another topic, I'm not happy with the solution I came up with for unifying the migration manuals on the docs website. I think i'll still work a bit on it to show what's left and what are the (nasty) shortcomings
<RP>
qschulz: ok, it is a tricky problem :/
<JPEW>
Is there a way to see the docs for un-supported releases (like gatesgarth?)
sakoman has quit [Quit: Leaving.]
agners has joined #yocto
<RP>
JPEW: I think the releases are in the index, just not in the drop down
sakoman has joined #yocto
<JPEW>
AH, "Outdated release manuals" Excellent
<qschulz>
yup
<qschulz>
or add the release number or release name after docs.yoctoproject.org/ in the URL
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<qschulz>
JPEW: and you'll see that the outdated release manuals is not up-to-date on e.g. dunfell version of the docs :/
<landgraf>
RP: thank you for your comment on dropbear/ssh conflict bug. I'll try to find proper place for exclude_complimentary. I had some ideas when I was fixing this in Oniro need to find them
Estrella has quit [Remote host closed the connection]
Estrella has joined #yocto
<RP>
landgraf: I'd wondered if we make things parallel install and have openssh "win" over dropbear but I think it would just confuse things more
manuel1985 has quit [Ping timeout: 268 seconds]
<ykrons>
Hi all
<ykrons>
I want to debug a recipe where the do_configure is changing the package source code, but if I do a bitbake -c devshell <recipe>, I get a shell but the do_configuration action have not been done. Is there a way to have do_configure applied in the devshell?
ptsneves has quit [Ping timeout: 268 seconds]
<qschulz>
ykrons: just run -c configure followed by -c devshell?
<ykrons>
that way it seems the changes are not applied
florian_kc has quit [Ping timeout: 252 seconds]
<ykrons>
I have just checked and the run.do_configure doesn't include my change, something is wrong somewhere else.
<zeddii>
I wondered about that. The kernel-source probably isn't in place before that install of the stdarg.h
<zeddii>
I never saw that locally. but could be racing.
PascalBach[m] has quit [Quit: You have been kicked for being idle]
<zeddii>
I'm trying a build after cleanall on linux-yocto and vboxguest drivers to see if I see it.
<RP>
zeddii: please don't promote cleanall, that should never be needed
<zeddii>
in my case, I need the new download, since I have fetched before with a local mirror of linux-yocto, and I don't want it to go into downloads for it.
Vonter has joined #yocto
<zeddii>
ahah. khem. yes, I see it now. I'll send a fix.
<zeddii>
I can cherry pick that into the various linux-yocto trees, I'll check the thread and see if the final has merged.
goliath has joined #yocto
<zeddii>
khem: vboxguestdrivers fixed. sending patch. Looking at perf now.
<zeddii>
there's about 7 patches in a block for the pull request for 6.0, at least grabbing this as another might be wise; tools bpf_jit_disasm: Fix compilation error with new binutils
<zeddii>
it'll be interesting to see what makes -stable out of them.
brazuca has quit [Quit: Client closed]
<wyre>
qschulz, sure it doesn't fix it because when I modify the .bbappend recipe I have it again and have again to rerun bitbake, but for some strange reason always I have the issue I just have it for a first time, the successive times I run bitbake it compiles properly. I'll try what you suggest and use the devtool to regenerate the patch 🤔
frieder has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<wyre>
qschulz, so should I run 'devtool modify linux-engicam'?
<wyre>
qschulz, not sure why apparently the devtool doesn't work https://bpa.st/PM4A
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<wyre>
it maps virtual/kernel to linux-engicam
<wyre>
which looks like the proper one, but not sure why standard.py throws that TypeError exception
zpfvo has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 268 seconds]
<khem>
zeddii: I also wonder if we should stop using libbfd in perf as default. Not only we have such API changes with major versions we also have GPL-2 and GPL-3 mixing there, we should perhaps start building perf with NO_LIBBFD=1 set.
<khem>
or make it a packageconfig where libbfd is disabled by default
<khem>
someone can still enable it if they need to.
argonautx has quit [Quit: Leaving]
nemik has joined #yocto
<zeddii>
a packageconfig makes sense to me. I don't use libbfd myself, so having it off wouldn't break me (and that's all that matters! ;) )
jmiehe has joined #yocto
prabhakarlad has quit [Quit: Client closed]
wkawka has quit [Quit: Client closed]
prabhakarlad has joined #yocto
<khem>
yes bubbles are nice and safe I agree 🙂
jmiehe has quit [Ping timeout: 268 seconds]
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
leon-anavi has quit [Remote host closed the connection]
<GregWilson>
I have a problem with the configuration of the display on a RPi4, we have been running without a problem on versions up to zeus with a display of 1024x600. We are trying to upgrade to hardknot and the display is not accepting the configuration. Is there anybody here that understands RPi4 display configuration and could help me understand what is
<GregWilson>
going on?
manuel1985 has joined #yocto
manuel1985 has quit [Ping timeout: 268 seconds]
Circuitsoft has joined #yocto
<zeddii>
khem: what's the right branch to build against the new binutils ?
<RP>
zeddii: it is in abelloni's test branch
<RP>
zeddii: ah. he dropped those
florian_kc has joined #yocto
<RP>
abelloni: btw, rerunning build for a warning doesn't work. It will pull from sstate the second time and mask it :(
<RP>
abelloni: we'll have to report that perf issue against the setuptools change I suspect
GregWilson has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 252 seconds]
florian_kc has joined #yocto
brazuca has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
gsalazar has quit [Ping timeout: 252 seconds]
ptsneves has joined #yocto
Adrian_ has quit [Ping timeout: 268 seconds]
GNUmoon2 has quit [Remote host closed the connection]