khem has quit [Quit: Connection closed for inactivity]
florian_kc has quit [Ping timeout: 264 seconds]
<landgraf>
Yocto is a tool as well as other buildsystem/traditional distro and it's up to user to choose proper tool for the task. and people choose the tool they know/have. That's why I use CNC router to cut simple shapes from plywood even if table saw will do the job better, because I don't know how to use table saw and I don't own one :-)
mvlad has quit [Remote host closed the connection]
Guest19 has joined #yocto
<Guest19>
The team maintaining the [__meta-raspberrypi__](https://github.com/agherzan/meta-raspberrypi) layer just added RaspberryPi5 support on master. Does anyone know how that ends up going from master to nanbield, or will it? I don't understand how that release flow works and I'm not sure who to ask.
<Guest19>
I'm realizing that this is controlled by other maintainers not the Yocto team so probably the wrong place to ask this question.
<landgraf>
Guest19: rpi5 support has been added few hours ago. I guess it's too early to merge into "stable" branches however you can ask maintainer in github issue (better with results of testing :) )
<Guest19>
Gotcha. Thanks for the reply
Guest19 has quit [Quit: Client closed]
kpo has joined #yocto
kpo has quit [Ping timeout: 256 seconds]
goliath has quit [Quit: SIGSEGV]
lexano has quit [Ping timeout: 264 seconds]
davidinux has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
ablu has quit [Ping timeout: 276 seconds]
ablu has joined #yocto
jclsn has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
jclsn has joined #yocto
sakman has joined #yocto
sakman has quit [Client Quit]
sakman has joined #yocto
mulk has quit [Ping timeout: 264 seconds]
olani has quit [Ping timeout: 260 seconds]
mulk has joined #yocto
astlep5504018 has quit [Quit: Ping timeout (120 seconds)]
astlep5504018 has joined #yocto
mulk has quit [Ping timeout: 264 seconds]
Saur has quit [Ping timeout: 260 seconds]
mulk has joined #yocto
Kubu_work has joined #yocto
linfax has joined #yocto
khazakar has joined #yocto
rob_w has joined #yocto
mckoan|away is now known as mckoan
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
mulk has quit [Ping timeout: 256 seconds]
mulk has joined #yocto
<LetoThe2nd>
landgraf: just looked at that sure thing, and my understanding is that it basically advertises https://github.com/aplanas/meta-microos - which is a re-load of meta-delian.
vladest has quit [Quit: vladest]
sakman has quit [Ping timeout: 246 seconds]
rfuentess has joined #yocto
<landgraf>
LetoThe2nd: yes, pretty much. More like meta-suse
<LetoThe2nd>
landgraf: *sigh*
<LetoThe2nd>
exactly what the world needs. another clever person shoehorning their own distribution into a Bitbake build. erm wait, in that case even explicitly into poky. *facepalm*
florian has joined #yocto
rber|res has joined #yocto
rber|res has quit [Remote host closed the connection]
rber|res has joined #yocto
Tyaku has joined #yocto
<Tyaku>
Hello, I have a variable in a recipe. How to make it configurable using a variable at build time ? I have it 'SW_REV ?= "Dirty"' in sw-revision.bb, it's not taking the value passed at buildtime (like: SW_REV='xxx' bitbake {...})
olani has joined #yocto
* RP
notes his patch doesn't work
<LetoThe2nd>
Tyaku: you mean, passing something into the build from the invoking environment?
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
vladest has joined #yocto
goliath has joined #yocto
<chep>
Hi, I'm trying to add python3 to my image (kirkstone branch). When I add « python3 » to CORE_IMAGE_EXTRA_INSTALL I got this error : « The following packages have unmet dependencies:
<chep>
python3-modules : Depends: python3-fcntl but it is not installable ». When I try to add « python3-fcntl » bitbake says that python3 RPROVIDES python3-fcntl. What should I do?
Saur has joined #yocto
<Tyaku>
LetoThe2nd Yes, Currently this is what I do: export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SW_REV" export SW_REV="${DIRTY_REV}" and then In the sw-revision.bb receipe I have SW_REV ?= "Unknown"
<Tyaku>
I don't know if it's the right way
xmn has quit [Ping timeout: 255 seconds]
<LetoThe2nd>
Tyaku: shouldn't it just be BB_ENV_EXTRAWHITE:append = "SW_REV"?
<michalsieron>
but at this point we have checked for donestamp and whether something needs update. so we *do* need to make a download
<michalsieron>
so why would we decide (after checking that repo in the download dir doesn't contain the commit we need) doesn't need to be downloaded from a PREMIRROR just because its directory already exists on the disk?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<landgraf>
michalsieron: we don't need to make a download from upstream if the revision is in PREMIRROR
<landgraf>
michalsieron: even more if PREMIRRORONLY is set we are not allowed to download from the network outside of premirror
<michalsieron>
landgraf: ok. so here is an example situation where I think the behaviour is buggy:
<michalsieron>
We have a recipe which requires commit 'abcd'.
<michalsieron>
We run `do_fetch` task for it, it clones the repository from let's say a premirror.
<michalsieron>
Later new commit appears for example 'wxyz'.
<michalsieron>
We update our recipe to require it and run `do_fetch` again (this time it has to be from a premirror).
<michalsieron>
First bitbake checks for `donestamp`, which exists, but then `need_update` returns true as we do need an update.
<michalsieron>
But then in `try_premirror` we check that the directory exists and decide we don't need to download from premirrors, even though just moment ago we concluded that we need to update.
<michalsieron>
This way we skip premirrors even though we really shouldn't.
olani- has joined #yocto
<landgraf>
michalsieron: which version? iirc we have test to cover this exact case
<landgraf>
if we don't it should be created
<michalsieron>
I am on kirkstone, but when I look at master it *looks* the same to me
<michalsieron>
landgraf: this is even more prone to happen if your premirror is a storage for git tarballs
<michalsieron>
then you run a build for one machine, which downloads full tarball (it wasn't updated to require shallow tarball)
<michalsieron>
and then another build for the second machine wants to download updated sources with a newer hash not present in the full tarball, which are present on premirror in a shallow tarball
<landgraf>
michalsieron: kirkstone doesn't have this fix iirc
<landgraf>
it was merged right after kirkstone has been released
olani- has quit [Remote host closed the connection]
olani- has joined #yocto
leon-anavi has joined #yocto
<michalsieron>
landgraf: I don't think it's the same. Please correct me if I understood the test incorrectly:
<michalsieron>
1. First we setup the test by downloading and preparing some tarball in our local premirror.
<michalsieron>
2. Then we set PREMIRRORS, BB_FETCH_PREMIRRORONLY and BB_NO_NETWORK
<michalsieron>
3. Finally we check we correctly downloaded from our premirror
<michalsieron>
For this to test the behaviour I described, it would require few more steps:
<michalsieron>
- In preparation you would need to have a shallow tarball with a commit not present in the normal one.
<michalsieron>
- After downloading the normal tarball, you would change SRCREV to one from the shallow tarball and try to download afterwards
prabhakarlad has joined #yocto
prabhakar has joined #yocto
<landgraf>
michalsieron: not sure I got the last point. Do you SRCREV presents in PREMIRROR's shallow clone but not in local clonedir ("normal tarball") ?
<landgraf>
*Do you mean
<landgraf>
michalsieron: or SRCREV is in PREMIRROR but not in DL_DIR?
ptsneves has joined #yocto
<michalsieron>
landgraf: SRCREV is present in shallow tarball, but not in not-shallow tarball
<michalsieron>
Think of it as shallow tarball was created for a commit after the non-shallow one was created
<landgraf>
michalsieron: not sure if shallow tarball is important here. For me it looks like: 1) make a tarball in the premirror 2) download(from the premirror)/build SRCREV1 3) add a commit SRCREV2 into premirror 4) download(from premirror)/build SRCREV2
<landgraf>
at step 3 you have premirror tarball with new srcrev and "original" one without
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
michalsieron has quit [Ping timeout: 250 seconds]
michalsieron has joined #yocto
<michalsieron>
landgraf: sorry, some internet issues
<michalsieron>
yes, you are right. shallow tarball is not actually required for this to manifest.
<michalsieron>
in both cases bitbake would incorrectly skip downloading from a premirror
<michalsieron>
landgraf: let me check if it solves the problem for me
<landgraf>
michalsieron: if it's not then let's open a bug. looks like I need more time to reproduce the issue
<michalsieron>
landgraf: because the commit subject says "fetch2: Honour BB_FETCH_PREMIRRORONLY option", but you don't need PREMIRRORONLY to say this is an issue
<michalsieron>
is some cases you want some sources to be fetched from a premirror, and some from your own upstream
<landgraf>
yes. you're right
<landgraf>
michalsieron: do you have YP bugzilla account?
<michalsieron>
nope
<landgraf>
michalsieron: I'll create bug report then to not have it lost in the irc conversation.
<michalsieron>
sure. if anything it will be closed as already fixed
<michalsieron>
landgraf: ok. I cherry-picked the commit and it still fails
<landgraf>
michalsieron: right. I see the issue now.
<landgraf>
michalsieron: it was masked by PREMIRRORONLY as you mentioned because there's check for it in try_premirror
rob_w has quit [Remote host closed the connection]
<michalsieron>
landgraf: oh. and you know what's the best thing? In my case all the actual mirrors are not trusted, so the build fails after skipping premirrors.
<michalsieron>
But if I run the build a second time, it will work again.
<michalsieron>
That's because bitbake will delete the tarball after failing to download from a mirror
RobW has quit [Quit: Leaving]
vladest has quit [Ping timeout: 246 seconds]
<landgraf>
michalsieron: and I have reproducer now.
jmiehe has joined #yocto
<michalsieron>
landgraf: great, so we can have a test for it. but there is still a question of how to fix it :D
jmiehe has quit [Quit: jmiehe]
<landgraf>
michalsieron: well. fix something in fetcher code is not so difficult. the question is how to fix it and not break something else :D
<landgraf>
I know how to "fix" that in Q&D way but RP will not be happy with the fix :)
<landgraf>
RP: long story short `git branch --contains` doesn't look into FETCH_HEAD so this part of code is useless :(
lexano has joined #yocto
<michalsieron>
landgraf: threre is still one thing I don't understand about this code.
<michalsieron>
From what I looked at this `Git.download` method, it tries to fetch changes with `git` not redownload actual tarball.
<michalsieron>
So if I have a generated tarball, which originates from the upstream, and the requested commit is not there, wouldn't `git fetch` access this upstream repository?
<michalsieron>
I would think, that download of the entire tarball is required, because that's how it is stored on the premirror. Binary storage can't really send you only things you are missing in your unpacked tarball.
<landgraf>
michalsieron: git fetch will try upstream if revision is in neither clonedir nor in premirror (unless premirroronly specified)
<landgraf>
michalsieron: clonedir -> premirror -> mirror -> upstream that's the proper order afaik but because of the bug you've found today premirror is effectively excluded from this if clonedir exists
<landgraf>
michalsieron: not really.
<michalsieron>
landgraf: I am not talking about order in which bitbake tries to download stuff
<landgraf>
michalsieron: --mirror is to setup a mirror of the repo, not to clone the mirror in bitbake terms
<landgraf>
michalsieron: in your case there're two issues. First (as you pointed out correctly) is the fact that premirror is set to false if clonedir exists and PREMIRRORONLY not specified, this is easy to fix. Second issue is the fact that fetcher doesn't see updated revision in the premirror, fixing this is more complicated
sakman has joined #yocto
<RP>
landgraf: this could be the issue paulg was asking about? :/
florian_kc has joined #yocto
<landgraf>
RP: Not with premirrors "2023-12-07 18:05:33 paulg no PREMIRRORS set". But we may have similar issue with another git fetch call below.
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
Vonter has quit [Ping timeout: 268 seconds]
Xagen has joined #yocto
Vonter has joined #yocto
ernstp has quit [Ping timeout: 268 seconds]
Xagen has quit [Ping timeout: 264 seconds]
nohit has quit [Ping timeout: 268 seconds]
roussinm has joined #yocto
ernstp has joined #yocto
nohit has joined #yocto
Xagen has joined #yocto
Tyaku_ has joined #yocto
<Tyaku_>
Hello, I'm back. These days I have serious problems, I don't know what my collegue do but lot of things are broken in our yocto projects. This is after some "refactoring" he split the image in multiples images, each one including another.
<roussinm>
When image is trying to do do_rootfs, it fails on: `file /etc/polkit-1/rules.d conflicts between attempted installs of polkit-group-rule-network-1.0-r0.zen2 and polkit-123-r0.zen2`, I tried to fix the bug, but can't figure out how do it since both recipe requires the pokit-1/rules.d directory. But recipes haven't changed in a while, so wondering if maybe it's not that used and we caught a bug in how
<roussinm>
those recipes are setup?
prabhakarlad has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
<yocton>
roussinm: check the ownership and rights of /etc/polkit-1/rules.d from both rules, they need to be the same
<roussinm>
yocton: chow and chmod needs to be the same I guess?
<roussinm>
chown*
<yocton>
roussinm: yes
simonew has joined #yocto
rfuentess has quit [Remote host closed the connection]
xmn has joined #yocto
linfax has quit [Ping timeout: 264 seconds]
simonew has quit [Quit: Client closed]
<qschulz>
RP: tlwoerner: JPEW: moto-timo: re: bmap-tools: meta-raspberrypi has a GitHub+ML contribution workflow already BTW, and it is hosted on git.yoctoproject.org.
<moto-timo>
as does meta-java (which is also on gitlab)... I am agnostic
<qschulz>
(I can comment on the ML, but here seems a bit more "private" to not make this blow out of proportions; I remember the few lengthy emails about webgui contributions in the past, don't want to revive those :) )
<qschulz>
does anyone have any idea why Intel is abandoning it? I'm quite surprised actually
<tlwoerner>
i don't think "intel" is abandoning ig
<RP>
qschulz: they don't have anyone working in this area anymore
<tlwoerner>
my understanding is that it was always the private project of the author... who happened to publish it on the corporate intel github account
<qschulz>
gotcha
<RP>
qschulz: the difference with rpi is which github account
<rburton>
iirc it was started by artem but very much used by some intel projects at the time
<RP>
tlwoerner: not really true, it was part of the tizen work originally
* tlwoerner
lives in his own reality which rarely intersects with actual reality
<tlwoerner>
intersects? interacts?
<tlwoerner>
;-)
<JPEW>
Well, if you all are figments of my imagination, at least my imagination figmented nice people :)
<RP>
tlwoerner: I think I should try that more! :)
geoffhp has quit [Remote host closed the connection]
simonew has quit [Quit: Konversation terminated!]
<roussinm>
Looking at documentation for BB_PRESSURE_MAX_MEMORY saying maximum is 1000000 but I see: full avg10=1.49 avg60=14.77 avg300=37.99 total=297837869, on my system. Using Kernel 5.4 did the value was changed since 4.20 ?
<roussinm>
Same for CPU actually: some avg10=0.01 avg60=5.08 avg300=29.38 total=18393902580 do I have to divide by the amount of threads ?