<mccc>
Hi, should $D be used in pkg_postinst_ontarget_${PN}? Docs suggest it should in pkg_postrm_${PN} which makes sense to match pkg_postinst_${PN} although I'd imagine postrm would only ever run on the device.
<otavio>
mccc: not really; you can end removing packages in a rootfs step and D could be used
<mccc>
Got it, okay thank you otavio.
otavio has quit [Remote host closed the connection]
sakoman has quit [Quit: Leaving.]
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
Vonter has quit [Ping timeout: 246 seconds]
Vonter has joined #yocto
rob_w has joined #yocto
frieder has joined #yocto
meck[m] has joined #yocto
hpsy has joined #yocto
zpfvo has joined #yocto
ant__ has quit [Remote host closed the connection]
camus1 has joined #yocto
camus has quit [Ping timeout: 255 seconds]
camus1 is now known as camus
tnovotny has joined #yocto
Neur0mante has joined #yocto
<Ch^W>
I reviewed a resume today that said they had used "Buildroot/Yocto" as the build system on a previous project. Remarkably, that was not the strangest thing I found on that resume.
zyga-mbp has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
florian has joined #yocto
<qschulz>
yates_home: PACKAGE_NO_GCONV is specific to recipes inheriting libc-package.bbclass. I'm not sure it makes sense to start listing what some classes do that makes FILES_ variable not work/or be not enough
<qschulz>
splatch: not sure to understand the request... what about making bzimage an artifact in the swupdate image so that it can be flashed on its own. On initial flash (or forced), everything will be reflashed so you'll be good to go.
<qschulz>
swupdate has support for AB partitioning AFAIR, you might just need to add some logic so that your bootloader knows which partition (A or B) to boot from
kanavin has quit [Remote host closed the connection]
<splatch>
qschulz: I do have A/B partition, but bzimage is on boot partition and that's something I haven't found a good solution, best would be to use bzimage from A/B partition to do not mess with boot contents
<splatch>
this was kind of surprise for me, cause I thought it will be as simple as "take partition A" and boot everything (including kernel) from there. It turns out to be different. Its not an issue of swupdate itself, cause I am pretty sure it can manage that. It is just lack of good examples to follow.
<qschulz>
splatch: so basically, you have A/B systems which selects a "rootfs" partition to boot, but in this rootfs you have /boot directory which can be updated from swupdate separately from the rootfs?
<splatch>
qschulz: let me have a look if I actually do
<qschulz>
I'm having a hard time understanding what your setup is and what your issue(s) is. Also... you might receive better help on the swupdate mailing list.. maybe they even have an IRC chan on some server?
<splatch>
qschulz: I think I just need to read a bit more on grub config and how to mount /boot from rootfsA or B. Then it should work. I am kind of delaying writing to swupdate mailing lists as I am still able to generate some progress (with screaming but still!)
<qschulz>
splatch: can your kernel be updated without the rootfs being updated?
JK has joined #yocto
<splatch>
qschulz: I hardly can imagine such scenario right now
<splatch>
for simplicity (of partitioning too) I would assume rootfs and kernel come together
<qschulz>
then just remove the kernel entry in sw-description? then use the same mechanism in grub as the one you gave earlier, which is reading boot artifacts from different partitions
<qschulz>
and add your kernel directly in the /boot directory with Yocto
<JK>
Dear gentlamem, is there any one who could help me to to solve the dependency ridle with yocto build ? The best might be dedicated channel such way I do not blast it here with logs.
<splatch>
my grub call is 'linux /EFI/BOOT/bzImage-initramfs rootwait root=LABEL=${boot_part} rootfstype=ext4', I am just thinking is it possible to make it look like 'linux ${boot_part}/boot/bzimage ...'
<splatch>
going to play a bit with virtualbox to see how it goes
<qschulz>
JK: pastebins exist so you can put your logs there and ask your question(s) here
<JK>
OK I will do ....
<JK>
thanks
<qschulz>
splatch: I think you should use the (hd0,2) part in the grub.cfg, adapted to your need obviously
<qschulz>
because linux /some/path is for grub and what's after is for the kernel (kernel command line). So the kernel knows about /dev/sdxx (or /dev/mmcblk, etc...) but grub does not use this convention
<splatch>
qschulz: yeah, now figuring out what rootfsA/B numbers are, if this will fly then I'm set
<qschulz>
splatch: I think you can list partitions from the grub terminal
<qschulz>
splatch: ls :)
<splatch>
qschulz: I am lucky enough to have virtualbox where both parts are the same.. sometimes I ask myself why I haven't become a carpenter, do you have sometimes similar feelings? ;)\
<JK>
Well the situation is following: I have inherited this project and my skill with yocto is limited. The bitbake was working till about 1 month ago. Then I have received the error that dependency of one company recept package is missing << No local packages or download links found for pbr>=1.9 >> My gues is that some other package stopped require this particular package and it broke the dependency (it might be badly defined). Thus I added the dependency in image
<JK>
recepy but the error remains. I have even tryed to create own recept for this package. I can see it by command bitbake-layers show-recipes but I still get the error ...
<JK>
My only gues is that the problem might be related to DEPENDENCY and RDEPENDENCY
<qschulz>
JK: missing DEPENDS +=
<qschulz>
"python-pbr" probably
<qschulz>
in python-tendo recipe
<JK>
well I have added this ...no change ....
<qschulz>
looks like it might be looking for python-pbr to run on the host and not on the target, so try DEPENDS += "python-pbr-native"
<qschulz>
also... Morty release? It's EOL for 3 years now :)
<qschulz>
otherwise, I've limited knowledge in python package recipes handling in Yocto, so if it still does not work, I can't suggest anything else..
<JK>
OK I will try and be right back ..... unfortunately I have too much to do on the project ... JS, python, VHDL etc.etc..... hw debuging ....
hpsy has quit [Ping timeout: 255 seconds]
<JK>
OK it seems it is working EXCELENT what is the difference in native package ?
mccc has quit [Ping timeout: 255 seconds]
<qschulz>
JK: native package runs on the host, during compilation, target package runs on the target as the name implies. You need a target dependency in DEPENDS for headers, shared libraries that are used by the linker
mccc has joined #yocto
<JK>
What I do not understand is that it was working in the past. And stoped working not long time ago .... As you sad Morty is old. It should be stable. Howevet thanks a lot I would not gues -native ever. One last question. Is it difficult to migrate yocto ? Thanks a lot for Your help. It is much appeciated. I have spend a week on it :D
<JK>
Now I need to try that the device is working correctly and not missing the package ....
<qschulz>
JK: it does not need the pythn-pbr package on the target most likely, so it won't appear in your image
mccc has quit [Ping timeout: 245 seconds]
<qschulz>
JK: two reasons: 1) host contamination, you had python-pbr installed on your desktop distribution and it disappeared or was uninstalled? 2) Morty still has bitbake-wide sysroot (it was changed in pyro to recipe-specific sysroot) which means if any recipe before python-tendo is built pulls the python-pbr-native recipe in the bitbake-wide sysroot, it'll be available to python-tendo. Obviously that
<qschulz>
means if DEPENDS aren't properly set, race conditions can occur. This also means if you happen to remove a recipe or package from your image or from dependencies of other packages, python-pbr-native might not make it to the bitbake-wide sysroot
<qschulz>
JK: migrating from bitbake-wide to recipe-specific sysroot is not always straightforward. There's also the jump from openssl 1.0 to openssl 1.1 probably, which might break your old source code if it does not get updated.
<splatch>
qschulz: building right now an older kernel release to test kernel downgrade :)
<qschulz>
But before getting you hyped up with a Yocto upgrade, I think anyone (at least those planning for an upgrade) should know the basics of Yocto otherwise it's going to be a nightmare and constant confusion
<qschulz>
JK: as always "It depends" (TM)
<qschulz>
if you have a lot of recipes, legacy code, etc... it might take some time and be non-trivial
<JK>
Yeah that is what I was thinking .... As I sad I inherited the project (not simple one) and I have to live with it as is ....
<qschulz>
that's why we usually recommend updating often so the jumps aren't so big :)
<qschulz>
JK: staying with morty also mean highly outdated sw, with unfixed security issues (and missing features/optimization/bugfixes, etc...)
<JK>
fortunately, the use is specific in stand alone mode (requested).....
xmn has quit [Quit: ZZZzzz…]
camus has quit [Ping timeout: 265 seconds]
<splatch>
I just did an upgrade from warrior to gatesgarth and it was a bit of pain due to changes in oe recipes and wireguard. Yet I would say someone with a minimum experience (as I am) was able to go through the process with container based builds. I did struggle a bit with host contamination, but it turned out to be my recipe error which I was able to trace with people's help here.
camus has joined #yocto
<splatch>
hence, looking at my experiences I could recommend isolating build so you don't get false positives or fighting with host setup
<JK>
what exactly you mean by isolating ?
<splatch>
I inherited a project (rather simple) which rely on docker builds
<splatch>
so I haven't installed nor configured poky on my host machine
<JK>
I am also using docker .... so basicaly I run from scratch ech time ....
hpsy has joined #yocto
<splatch>
JK: then you are in good place to start your transition. I found for example that I had to add DEPENDS or adjust RDEPENDS variables over the way. If you try going every second release maybe you will be finally able to streamline configs and get issues sorted.
<splatch>
I consider myself a n00b here (I run linux on daily basis, but that'd be it). I could not for example sort my build with zeus cause lack of time, then did two attempts with dunfell which also did not succeeed for various reasons. I guess sometimes it is a matter of luck and advices from people here!
jsandmand has joined #yocto
<JK>
OK thanks a lot, I will go now to continue in my work to fix firmware :) Something that I am a week delayed from by yocto :/
<splatch>
JK: welcome in the club :)
<splatch>
we're waring same schoes
jsandmand is now known as jsandman
<JK>
:D yeah ..... but I am HW engineer :D I am dealing with SW now and it is a lot to learn ...
<jsandman>
Hi! I'm trying to generate flashable image using some tools from my bsp provider. For that I added a MACHINE-bsp-native recipe to be used in the image recipe. I am trying to add a DEPENDS_machine += "machine-bsp-native" in my image recipe but I get a 'No such file or directory: 'cross-localedef'' error when the image recie does the do_rootfs stuff.
<jsandman>
Any ideas why I am getting this?
<splatch>
jsandman: are you doing anything with gconv or localdef in your build?
<jsandman>
I can't really tell right now. there are many components. At least for this bsp tool that should not be the case
<jsandman>
The thing is. If I just do DEPENDS += "machine-bsp-native". I seem to get the sysroot populated correctly. The problem comes when I do a pre-machine dependency with DEPENDS_machine += "machine-bsp-native"
<qschulz>
jsandman: DEPENDS_append_machine = " machine-bsp-native" then I assume is what you want
<qschulz>
also... I think you might want to have a look at IMAGE_CMD and add your own, and you can select it with IMAGE_FSTYPES IIRC in your machine.conf then i think there's an IMAGE_DEPS or something like this to specify on which rative recipe your IMAGE_CMD depends on
<qschulz>
poky/meta/classes/image_types.bbclass is where most are defined
<jsandman>
Yeah! That seems to be working now. Thank you very much qschulz. I'll check that talk of yours. It will sure clear some things up.
<jsandman>
Thanks for the advise! I'll check that IMAGE_CMD too ;)
<qschulz>
jsandman: my pleasure, have fun!
goliath has joined #yocto
radek has joined #yocto
jwillikers has joined #yocto
Neur0mante has quit [Ping timeout: 246 seconds]
xmn has joined #yocto
Vonter has quit [Ping timeout: 255 seconds]
Vonter has joined #yocto
kayterina has joined #yocto
mranostaj has quit [Ping timeout: 258 seconds]
mranostaj has joined #yocto
Dracos-Carazza_ has joined #yocto
hpsy has quit [Ping timeout: 265 seconds]
Dracos-C- has joined #yocto
Dracos-C- has quit [Read error: Connection reset by peer]
Dracos-Carazza has quit [Ping timeout: 272 seconds]
Dracos-Carazza_ has quit [Ping timeout: 268 seconds]
<thekappe>
hello guys
<thekappe>
while trying to bitbake my image, I got the following error:
<thekappe>
Uninative selected but not configured correctly, please set UNINATIVE_CHECKSUM[x86_64]
<thekappe>
I've also had some previous problem with poky's uninative bbclass since the os.path.exists(loader) return with error. I fixed it (hopefully) changing it to os.path.exists(str(loader))
<RP>
Perhaps we just have to start simple with this. Fixing that would then give the parser more options as we'd actually know what was an override and what was not
<RP>
That will be a major pain to migrate to but I'm starting to think we're pinned in without doing it
<RP>
Apart from the conversation, the package code will need heavy changes I suspect
<RP>
since access to RDEPENDS
<RP>
since access to RDEPENDS_${PN} no longer works
<RP>
JPEW: certainly it was intended to be but it is used half and half
<JPEW>
Hmm
<JPEW>
hmm
<qschulz>
RP: thanks for laying down your thoughts on the mailing list. I had a hard time following yesterday :)
<qschulz>
RP: I'll answer on the mail later, just a few questions: what about ??= and ?=, would yo have a FOO_weakval_weakval and FOO_weakval_defval?
<RP>
qschulz: weakval is ??=, I was ignoring ?= for now ;-)
<RP>
?= doesn't really equate well to overrides
<qschulz>
RP: what happens when you have FOO += "bar" followed by FOO = "baz"?
<RP>
today, baz gets set and bar gets dropped
<qschulz>
but... why?
<RP>
qschulz: because that is the way the language is setup
<qschulz>
because FOO += "bar" is actually FOO_defval_append IIUC
<RP>
qschulz: right, in a new world, it becomes problemtic
<qschulz>
If the changes are just internal (i.e. recipes do not need to change anything to be compatible with the next release), then it's fine. If it changes anything in the behavior (such as FOO += "bar" FOO = "baz" with the current suggestion), I feel like it's fine to also change the override delimiter from _ to :
<qschulz>
since we're going to require changes anyways
<RP>
qschulz: the question is whether someone looking at the metadata can know what the correct change is
<JPEW>
qschulz: Some of your Pyrex changes don't pass the format check (run `black .`)
<qschulz>
JPEW: bad qschulz, bad.
<RP>
I'm ok to require changes to the metadata but I'm not sure we want to do things which create hard to find bugs
<JPEW>
RP: Is the expectation that the resulting recipes populate the same end variables in the datastore? I feel like a tool could be written to validate that
<RP>
JPEW: I did kind of start one. I'm thinking that could be useful to check
<RP>
it wouldn't cover things like the dynamic packaging code :/
<vmeson>
We've been having trouble with the Yocto Autobuilder load, if you'd like to help out or just find out what's going join: https://windriver.zoom.us/j/3696693975
<RP>
This is a meeting about trying to figure out the intermittent bugs
RobertBerger has joined #yocto
Dracos-Carazza has quit [Read error: Connection reset by peer]
rber|res has quit [Ping timeout: 252 seconds]
Dracos-Carazza_ has joined #yocto
<qschulz>
JPEW: kas actually disables known_hosts check in the container, would you be open to something similar for pyrex container images?
<JPEW>
Eww, that's kinda terrifying :) What does the change look like (maybe we can make it optional)
rber|res has joined #yocto
RobertBerger has quit [Ping timeout: 245 seconds]
Neur0mante has quit [Quit: Client closed]
nerdboy has quit [Ping timeout: 265 seconds]
<thekappe>
hello guys, while trying to bitbake my image, I got the following error:
<thekappe>
Uninative selected but not configured correctly, please set UNINATIVE_CHECKSUM[x86_64]
<thekappe>
I've also had some previous problem with poky's uninative bbclass since the os.path.exists(loader) return with error. I fixed it (hopefully) changing it to os.path.exists(str(loader))
<thekappe>
I'm building from gatesgarth
hpsy has joined #yocto
Neur0mante has joined #yocto
radek has quit [Remote host closed the connection]
radek has joined #yocto
<lukma>
I do have a question - what is procedure to get new layer added to:
<JPEW>
v2d I don't know what you laptop is like but that would build pretty slow
<rburton>
the problem with mini stuff is the airflow sucks, which is the same problem you have with laptops
<v2d>
true
<JPEW>
v2d: I would take rburton advice and build a tower. Maximize CPU, I usually recommend 2-4 GB RAM per CPU core, and SSD disk if you can afford it
<v2d>
JPEW like 8-16Go RAM for a quad-core for instance?
<JPEW>
v2d: Ya
<rburton>
my last traditional builder was a dual socket xeon with 64gb of ram
<v2d>
damn
<v2d>
poky from scratch in 10 seconds
<rburton>
ha i wish
<rburton>
this was five years ago :)
<v2d>
64gb ram might not be enough for yocto anyway :>
<JPEW>
v2d: My current builder is a 18c/36t i9 with 64G RAM (not what I buy for myself though; AMD is better value)
<v2d>
is AMD better than intel for builds ?
<rburton>
its typically slightly better value for money
Tyaku has joined #yocto
<v2d>
do I need a big ass tower or is there a smaller case without compromising the air flow that you would recommend?
<Tyaku>
Hi, I would like to know what are the best practices to create a Yocto project under Git ? In my idea: One folder with submodules for all the "meta-*". The question is: What about the "build" folder with conf/local.conf and bblayers ?
<rburton>
don't put that in git
<Tyaku>
Is there a document somewhere that describe it ?
sakoman has joined #yocto
<Tyaku>
<rburton> What do you mean by "that" ?
<rburton>
build/ should never be in git
<Tyaku>
so, how do you share the bblayer and local.conf ?
<rburton>
submodules work if you can handle them. your layer can ship a template local.conf so creating a new build tree does the right thing out of the box.
<v2d>
Tyaku the idea is that the local.conf should only contains your personally local tweaks, but it is often misused to carry shared stuffs. To simplify sharing a configuration with your workmates or whoever, look at tools like "kas" or "whisk" on github
<Tyaku>
Ok, i will check, but with the templates you are also able to store the bblayers ?
<LetoThe2nd>
yo ddX
<qschulz>
LetoThe2nd: o/
<rburton>
Tyaku: have a look at my example and you'll see
<LetoThe2nd>
qschulz: \o \m/
<v2d>
Tyaku for example kas generates the local.conf and bblayers.conf for you from a .yml file describing your project. This yml file is what you track with git. Whisk should work likewise
<Tyaku>
So what is the best with <rburton> solution ?
<Tyaku>
I think <rburton> solution is working out of the box (i see the .sample files)
<rburton>
the sample thing is separate from the kas thing
<rburton>
and both *work*
<rburton>
they're just different choices
<Tyaku>
Wep I understand
<rburton>
'should I draw a picture with pens or pencils' doesn't have a single answer
<rburton>
personally, i use kas for our CI setup and I like it
<RP>
rburton: crayon ;-)
<v2d>
I personally avoid git submodules if I can, but that's just me.
<Tyaku>
Yep thats another question. I think it depends if you need to use your meta for another projects
<Tyaku>
Thank you <rburton> and <v2d>
<fray>
I'm stepping into the middle of the conversation, but tracking multiple recipes instead of using a .yml or other file, RP and I had talked about using bblayers.conf or similar to control the setup and updating. (Yes, it becomes OE specific, but the setup could then be part of bitbake directly.)
rber|res has quit [Ping timeout: 255 seconds]
RobertBerger has joined #yocto
Neur0mante has quit [Quit: Client closed]
camus has quit [Ping timeout: 258 seconds]
camus has joined #yocto
<v2d>
fray not sure I follow. You'd put all tweaks from the has yml file in the bblayers.conf? how would you describe the images to build?
kayterina has quit [Remote host closed the connection]
florian_kc has joined #yocto
<fray>
v2d no 'tweaks'.. the bblayers.conf would have contained all of the references to the repositories, and then a bitbake component could read it and fetch (and manage) them..
<fray>
the fetch could be done by repo, git submodules, etc etc etc. The how wasn't important, it was the common control language
camus has quit [Remote host closed the connection]
camus has joined #yocto
<JPEW>
fray: That's basically what we did with whisk
<v2d>
JPEW I might poke you in the next weeks about whisk, I do use kas at the moment to centralize the config, but I'm not fully satisfied with it, and I will likely use multiconfig to split builds for vanilla/dev/customer images, etc. Sooo, ... ;-)
<JPEW>
v2d: Sounds good
<v2d>
btw what is the recommended way to clone private repositories from a local container? Mounting ~/.ssh sounds like a bad idea, is an ssh agent safer?
<qschulz>
yes, it's safer, in that it's not giving your private key
<v2d>
way to go then
<v2d>
thank you qschulz
<qschulz>
you need to mount the file pointed by $SSH_AUTH_SOCK and pass the appropriate SSH_AUTH_SOCK env variable too
<qschulz>
you can check if it works by using ssh-add -l in your container, if you get something, all good 👌
sgw has quit [Remote host closed the connection]
Tyaku has quit [Quit: Leaving]
tnovotny has quit [Quit: Leaving]
sgw has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
<v2d>
qschulz you mount SSH_AUTH_SOCK read-only, right?
zpfvo has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
mckoan_ has quit [Ping timeout: 258 seconds]
mckoan|away has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<qschulz>
v2d: no, is it working if ro?
v2d has quit [Quit: Client closed]
paulg has quit [Remote host closed the connection]
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
boo has joined #yocto
whuang89 has joined #yocto
<whuang89>
hi.. im not sure why I keep getting this error on the do_rootfs stage:
<whuang89>
Collected errors:
<whuang89>
* Solver encountered 1 problem(s):
<whuang89>
* Problem 1/1:
<whuang89>
* - nothing provides gstreamer1.0-python needed by python3-kivy-2.0.0-r0.aarch64-mx8mp
<whuang89>
*
<whuang89>
* Solution 1:
<whuang89>
* - do not ask to install a package providing python3-kivy
<whuang89>
gstreamer1.0 is provided in openembedded laer
prabhakarlad has joined #yocto
<whuang89>
and my kivy recipe isn't asking for it =/
LetoThe2nd has quit [Quit: Connection closed for inactivity]
nerdboy_ has joined #yocto
v2d has joined #yocto
nerdboy has quit [Ping timeout: 240 seconds]
nerdboy_p has joined #yocto
nerdboy_ has quit [Ping timeout: 265 seconds]
nerdboy_p has quit [Ping timeout: 255 seconds]
prabhakarlad has quit [Quit: Client closed]
hpsy has quit [Ping timeout: 258 seconds]
dev1990 has joined #yocto
frieder has quit [Remote host closed the connection]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
v2d is now known as vd
zyga-mbp has joined #yocto
<smurray>
JPEW: I don't see any hash equiv specific testcases in oe-selftest, is the theory all tests are getting run with it because it's the default in poky?
<RP>
smurray: try lib/bb/tests/runqueue.py from bitbake-selftest