LocutusOfBorg has quit [Read error: Connection reset by peer]
LocutusOfBorg has joined #yocto
Ablu has quit [Ping timeout: 240 seconds]
Ablu has joined #yocto
GParker_ has joined #yocto
geoffhp has quit [Ping timeout: 272 seconds]
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
GParker__ has joined #yocto
GParker_ has quit [Ping timeout: 255 seconds]
alimon has quit [Ping timeout: 255 seconds]
alimon has joined #yocto
amitk has joined #yocto
GParker_ has joined #yocto
GParker__ has quit [Ping timeout: 248 seconds]
GParker__ has joined #yocto
GParker_ has quit [Ping timeout: 260 seconds]
Guest98 has joined #yocto
alessioigor has joined #yocto
rob_w has joined #yocto
GParker_ has joined #yocto
GParker__ has quit [Ping timeout: 258 seconds]
wacke has joined #yocto
<wacke>
good morning channel, someone tried to build meta-qt6 on hardknott? readme says it's supported, but i always get GLIBCXX_3.4.30 not found, looked it up, it's part of uninative, the latest which comes with hardknott is 3.5, GLIBCXX_3.4.30 is in 3.6. what should i do? upgrading to kirkstone is not an option atm
<wacke>
thx
skokkonda has joined #yocto
goliath has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Estrella__ has joined #yocto
Estrella___ has joined #yocto
Estrella____ has quit [Ping timeout: 272 seconds]
Estrella_ has quit [Ping timeout: 272 seconds]
mckoan|away is now known as mckoan
alberto_pianon has joined #yocto
mvlad has joined #yocto
luc4 has joined #yocto
Kubu_work has joined #yocto
rfuentess has joined #yocto
Schlumpf has joined #yocto
davidinux has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
alberto_pianon has quit [Ping timeout: 245 seconds]
GParker__ has joined #yocto
GParker_ has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
alberto_pianon has joined #yocto
<alberto_pianon>
Hi! I'm still working on a PoC implementation of the source tracer API and I ran into a feature that I'm not sure I'm understanding correctly: in SRC_URI multiple 'name' and 'branch' parameters may be set for the same URL, but IIUC this is needed just to fetch multiple revisions in case of shallow cloning, but only the first "name" will be checked out, is that right?
<mckoan>
alberto_pianon: Ciao! Not sure to understand. Can you be more specific?
alberto_pianon has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<qschulz>
landgraf: agreed. The thing is that how the commit log is formulated seems to indicate it is supported. So 1) it is indeed supported, then we're missing documentation update (not asking Talel to do it though) and maybe selftest or something like that
luc4 has quit [Quit: Konversation terminated!]
<qschulz>
landgraf: 2) if it isn't supported but doing this wrong thing is breaks the code, then it should be "documented" in the commit log that this is fixing just an error and not merely stating we support this case :)
<landgraf>
qschulz: Yup. I've replied with simple test request.
<landgraf>
qschulz: 2) agreed :) or drop the code if it's not needed/supported
luc4 has joined #yocto
alberto_pianon has joined #yocto
<qschulz>
landgraf: looking at the code quickly, it does seem supported indeed
<landgraf>
alberto_pianon: nocheckout stuff is different story I think
alberto_pianon has quit [Read error: Connection reset by peer]
alberto_pianon has joined #yocto
frieder has quit [Ping timeout: 255 seconds]
bhstalel has joined #yocto
GParker_ has joined #yocto
<alberto_pianon>
landgraf: the thing that I need to be sure of is that only the branch revision associated with the first name is checked out and used to build the component, while others are just fetched for... reasons, which however do not matter for what I need to do (trace upstream sources used to build the component)
GParker__ has quit [Ping timeout: 240 seconds]
<landgraf>
alberto_pianon: I *think* it's possible to fetch both names into subdirs and use them for building of the component or at least I can see this as the original idea of having multiple names/branches. I've not found any test case covering this though so it may be good idea to create one. RP can confirm (or not confirm) this.
alberto_pianon has quit [Read error: Connection reset by peer]
frieder has joined #yocto
xmn has quit [Ping timeout: 255 seconds]
alberto_pianon has joined #yocto
wacke has joined #yocto
leon-anavi has joined #yocto
alberto_pianon has quit [Read error: Connection reset by peer]
<RP>
alberto_pianon: I think we supported that when linux-yocto was a merged tree without separate metadata. We don't do that now and I suspect it was the only user
kalj has joined #yocto
kalj has quit [Client Quit]
bantu has quit []
bantu has joined #yocto
alberto_pianon has joined #yocto
<dvergatal>
RP: I have managed to run tar-native instead of host, verified and it's working but not yet for sstate which I still need to implement
alberto_pianon has quit [Read error: Connection reset by peer]
<dvergatal>
RP: in addition I have a question, do we want to have a verification that tar from host is < 1.35 and only than use the the tar-native?
GParker__ has joined #yocto
<RP>
dvergatal: no, it will be too hard to make that work
GParker_ has quit [Ping timeout: 252 seconds]
<RP>
dvergatal: I am a bit worried about how this will work for things installed from sstate :(
<RP>
no target sstate can be processed until tar-native is present :(
<RP>
that is a really nasty build bottleneck
<dvergatal>
RP: yeah i know
davidinux has quit [Quit: WeeChat 3.5]
<dvergatal>
RP: ok so no check for the version?
<RP>
dvergatal: I don't see how you'd keep the task checksums stable
<dvergatal>
RP: that is what I was afraid of ok I will finish than with sstate and push the new commits
<landgraf>
RP: I've written (very simple) test and looks like Alberto is right, only first ['name/branch'] is being unpacked with fetcher.unpack(). Good news it works in my fake "PREMIRRORS" test environment and I can submit it for review :)
<RP>
landgraf: right, it is assumed the recipe would do what it needed with the other revision
bhstalel has quit [Ping timeout: 245 seconds]
bhstalel has joined #yocto
florian_kc has joined #yocto
alberto_pianon has joined #yocto
davidinux has joined #yocto
alberto_pianon has quit [Read error: Connection reset by peer]
azcraft has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
azcraft has quit [Client Quit]
azcraft has joined #yocto
rber|res has joined #yocto
Vonter has quit [Ping timeout: 272 seconds]
Vonter has joined #yocto
azcraft has quit [Quit: Leaving]
azcraft has joined #yocto
skokkonda has quit [Quit: Client closed]
azcraft has quit [Client Quit]
<luc4>
Hello! What is the proper way to add a user to some groups? I added the user with the useradd class. I tried to add the user like this: USERADD_PARAM:${PN} = "-d /home/touch -r -m -s /bin/bash -p ... -U -g touch touch". It seems I'm getting a huge amount of errors like this: "warning: package architecture (armhf) does not match system (amd64)". Any idea why?
<rburton>
those warnings are unrelated to adding a user
<luc4>
rburton: it happens specifically when I change the params in that command
<luc4>
rburton: removing -g ... fixes it and everything works.
<luc4>
rburton: no idea why
florian_kc has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
<rburton>
first i'd suggest not using dpkg, it's the least tested of the package backends
<rburton>
if you can replicate with a minimal example then that would be interesting
<luc4>
rburton: ouch...
<luc4>
rburton: any other way to add the user to a list of groups?
<rburton>
that class is how i'd do it
<rburton>
as i said, a minimal test would be interesting
<luc4>
rburton: I tried to usermod in do_install, but it doesn't seem to work well
<rburton>
yeah that won't work
<rburton>
how would it modify the target passwd file?
<landgraf>
luc4: sysusers if you're using systemd
<luc4>
landgraf: trying it, thanks!
<luc4>
landgraf: is it usable in a ro image?
rohieb has joined #yocto
<landgraf>
luc4: file a bug if it's not
skokkonda has joined #yocto
skokkonda has quit [Client Quit]
<rohieb>
I'm getting errors on git pull in poky.git that the tags for 4.0.13 have changed. Is this legit?
<rohieb>
my local version refer to commit e51bf557f596 (tag: yocto-4.0.13, tag: kirkstone-4.0.13) So 2023-09-24 10:53:54 (Steve Sakoman) build-appliance-image: Update to kirkstone head revision
<paulbarker>
I expect a lot of behind the scenes work has been needed to secure that so congrats to all involved
ptsneves has quit [Ping timeout: 255 seconds]
ptsneves1 is now known as ptsneves
<RP>
paulbarker: It has and is taking a bit of pulling together but hopefully worth it!
<mcfrisk>
cool! I wish the funding would cover longer holidays for RP and means of delegating issues and maintenance work to other developers
<luc4>
landgraf: is it sufficient to add the conf file to sysusers.d to create the users? Or should I add something else to have those users created at build time?
skokkonda has joined #yocto
<landgraf>
luc4: first of all make sure systemd is configured with sysusers enabled
<qschulz>
RP: congrats!
<luc4>
landgraf: systemd is working fine, so that should be ok. Not sure about sysusers enabled. I see other conf files in /usr/lib/sysusers.d so I guess it is... or should I enable it explicitly somewhere? I couldn't find any example about this.
<landgraf>
luc4: you should know your setup/project better than I do because I know about nothing about it :)
<luc4>
landgraf: I understand that, thanks for your help though.
<landgraf>
luc4: add files under sysusers.d and if doesn't work you'll have to find the reason...
<landgraf>
happy debugging :-)
<landgraf>
RP and all involved: Congrats!
<luc4>
landgraf: thanks :-) thanks for the useful hint about sysusers, didn't know what it is
alberto_pianon has joined #yocto
alberto_pianon has quit [Read error: Connection reset by peer]
alberto_pianon has joined #yocto
alberto_pianon12 has joined #yocto
alberto_pianon has left #yocto [#yocto]
varjag has joined #yocto
alberto_pianon12 has left #yocto [#yocto]
<varjag>
is AUTOREV supposed to still work in Kirkstone?
<varjag>
looks like it broke for us after migration
alberto_pianon has joined #yocto
<varjag>
"Exception: bb.fetch2.FetchError: Fetcher failure: Recipe uses a floating tag/branch 'master' for repo '<...>' without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev()"
<landgraf>
varjag: Specify SRCREV
<varjag>
it is specified as AUTOREV
alberto_pianon has quit [Client Quit]
<qschulz>
varjag: IIRC you need to provide SRCPV inside PV or something like that
<mcfrisk>
RP: glad that workaround works, sad that it's needed :|
<RP>
mcfrisk: me too but I'm having to be pragmatic on this one
<RP>
mcfrisk: at least showing the warning occasionally might encourage us to root cause it
Daanct12 has quit [Ping timeout: 260 seconds]
bhstalel has quit [Quit: Client closed]
bhstalel has joined #yocto
<bhstalel>
I want to ask about something, if I send a PATCH that does not have a Bug (I even don't attend meetings) and time passes without response to that PATCH, what does that mean? Long review time or something else ?
<landgraf>
bhstalel: it means release is coming and maintainers are busy =)
<qschulz>
bhstalel: it all depends how long is "long" for you (and the maintainers). 1) Contributions to OE-Core and Bitbake very often are merged without notice, so check in the git repos if your patches haven't made it already
<qschulz>
bhstalel: 2) if we're near an rc1 or a release, things may tak longer than usual. This is currently the case.
<qschulz>
bhstalel: 3) Replying to your own patch mail and asking if people have things to say about it is usually the way to go with it
<landgraf>
bhstalel: your first patch has few review comments to be addressed. second one has been sent today (so not "long" in any sense)...
<bhstalel>
Thanks for the clarification, just one last question, if I send a PATCH that is not related to a specific branch like "kirkstone", if it is merged, I got notified or in which branch it will be merged ? "master" ?
<landgraf>
bhstalel: 4) Patch will go to testing and it will take some time too (as we're near the rc1/release it can take longer).
<qschulz>
bhstalel: it'll always be master-next (or next?) first, then it'll land into master if it didn't break anything during automated testing
<bhstalel>
landgraf Yes, I am just asking a generic questions in order to prevent any misunderstanding from my side.
<qschulz>
bhstalel: you'll typically not receive a notification (see my 1) ) when it gets merged
<landgraf>
qschulz: it's in -contrib's master-next, then master-next and then (hopefully) master
<qschulz>
bhstalel: if you want things to be backported to earlier release, you need to resend a patch or cc the release maintainer
<bhstalel>
qschulz That's interesting because I did the work on kirkstone, and since it is LTS, the PATCH should be sent with prefix "[kirkstone][PATCH]" and to the maintainer of that branch ?
<rburton>
RP: balls posted more console fixes but in the middle there's a meta-yocto-bsp commit.
Daanct12 has joined #yocto
<qschulz>
bhstalel: so mmm.... this should NOT be done this way
<qschulz>
bhstalel: first write the patch for the master branch and test it on the master branch
<qschulz>
send it to master
<qschulz>
I mean, to the mailing list, for the master branch (which is the assumed default)
<qschulz>
if then we need to backport it and it's trivial (e.g. a simple cherry-pick is simple), you can ask the stable release maintainer to do it, or send them a patch directly with e.g. [kirkstone] in the mail prefix
<landgraf>
bhstalel: all fixes should go to master first
<landgraf>
otherwise you've a regression
<RP>
rburton: I can handle that
<qschulz>
though it usually need to be backported to ALL currently supported releases, not only the one you're interested in :)
<RP>
rburton: no SoB
<RP>
rburton: only my SoB on 2/5 as well?
<landgraf>
bhstalel: if the fix is branch specific and master is NOT affected then fix should be send to [branch]
<rburton>
gar
<bhstalel>
That's clear, for my recent PATCH, I just need to test it on master, because I already sent a PATCH.
<bhstalel>
Then I need to send the patch again with kirkstone prefix and CC the maintainer of the branch.
<RP>
rburton: you can join vmeson in the "unable to send a patch" corner :)
<rburton>
bhstalel: if you're backporting a fix for kirkstone then you should also backport for mickledore. otherwise someone upgrades from kirkstone to mickledore and your fix disappears
<landgraf>
bhstalel: just take a look how it's done by others
<bhstalel>
If I test the PATCH on all branches starting from kirktone to master and it works, then I need to send the PATCH as many as the number of branches I tested on ?
<landgraf>
bhstalel: so the rule is fix *MUST* land in all supported branches down from master to <your target branch>
<bhstalel>
landgraf Non-EOL branches to be specific ?
<landgraf>
bhstalel: you send to master, wait until it merged and then send to release branches if needed (and if maintainer haven/t pick them yet)
<landgraf>
bhstalel: yes
<bhstalel>
Ok, so for now, no need for me to send for kirkstone or mickledore.
<bhstalel>
I already sent the PATCH, so now I wait.
<bhstalel>
Now it is clear for me, thanks for the clarification, this helps alot avoiding conflicts and misunderstanding in the future.
<landgraf>
bhstalel: and if the fix is for the component it becomes more complicated but it's differnt story ) the general rule is "Upstream first" still applies
skokkonda has quit [Quit: Client closed]
<landgraf>
bhstalel: I see now both your patches got attention =) problem solved!
<Guest76>
inside the bb recipe there is a line like this: inherit ${@bb.utils.contains('PACKAGECONFIG', 'python3', 'distutils3-base', '', d)}. can i override this in bbappend?
<Guest76>
i don't want to do it in bb. the override i want to do: inherit ${@bb.utils.contains('PACKAGECONFIG', 'python3', 'setuptools3-base', '', d)}
Guest98 has quit [Quit: Client closed]
<mrdmitry>
Is there a recommended way of ordering useradd postinst calls or their ordering is arbitrary and cannot be enforced through bitbake?
<qschulz>
Guest76: I don't think you can do this, nor "un"-inherit a class
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
Xagen has quit [Ping timeout: 252 seconds]
luc4 has joined #yocto
<yates_work>
is extend_recipe_sysroot a standard task or function?
Guest76 has quit [Quit: Client closed]
Estrella__ has quit [Remote host closed the connection]
bhstalel has joined #yocto
Estrella_ has joined #yocto
<rburton>
yates_work: '$ git grep extend_recipe_sysroot' doesn't have any addtask lines, so it's not a task
<rburton>
RP: bah qemuarm failed, i wonder why that's different
<yates_work>
ok
ctraven has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
ctraven is now known as sotaoverride
zpfvo has joined #yocto
frieder has quit [Ping timeout: 272 seconds]
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
<RP>
rburton: I have some memory of jonmason working on a fix before we could enable it?
GParker_ has joined #yocto
Daanct12 has quit [Ping timeout: 260 seconds]
GParker__ has quit [Ping timeout: 255 seconds]
<rburton>
we test it in our CI though
frieder has joined #yocto
goliath has quit [Quit: SIGSEGV]
<bhstalel>
RP Regarding your reply on my patch about BBFILE_COLLECTIONS, I will ask a question here to keep the emails only for review remarks and PATCHs:
<bhstalel>
Regarding your comment:
<bhstalel>
Do you mean using addpylib can be an alternative for not setting BBFILE_COLLECTIONS and BBPATH ? If yes, I can't see an example on how to do that.
zpfvo has quit [Ping timeout: 258 seconds]
<qschulz>
bhstalel: please send the answer to the mail so people don't need to come to IRC to follow up the review on patches :)
<qschulz>
and it also allows people other than RP to answer to your questions as well :)
<bhstalel>
qschulz I thought I'd avoid ping-pong in emails, so it is okay to ask back on emails ?
zpfvo has joined #yocto
<bhstalel>
Done.
<qschulz>
bhstalel: of course :) there can be a lot of back and forth, but 1) this allows people finding your patch to know the status of the review/discussion and 2) allow other people to chime in :)
kaitsh has joined #yocto
bhstalel has quit [Quit: Client closed]
frieder has quit [Ping timeout: 240 seconds]
<jonmason>
the only thing I have qeueued is fixes in meta-arm for the coming kernel breakage/fixes
Chaser has joined #yocto
sanbeam_ has joined #yocto
pidge has joined #yocto
florian_kc has joined #yocto
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
rfuentess has quit [Remote host closed the connection]
Chaser has quit [Quit: Chaser]
florian_kc has quit [Ping timeout: 260 seconds]
luc4 has quit [Ping timeout: 240 seconds]
sanbeam9 has joined #yocto
GParker_ is now known as geoffhp
sanbeam_ has quit [Ping timeout: 255 seconds]
amitk has quit [Remote host closed the connection]
amitk has joined #yocto
Xagen has joined #yocto
bhstalel has joined #yocto
sanbeam9 has quit [Ping timeout: 255 seconds]
wacke has quit [Ping timeout: 272 seconds]
Guest22 has joined #yocto
zpfvo has quit [Remote host closed the connection]
Guest22 has quit [Client Quit]
leon-anavi has quit [Quit: Leaving]
xmn has joined #yocto
brrm has quit [Ping timeout: 255 seconds]
<halstead>
rburton: yes, the signed tags for 4.0.13 were redone a few hours after they were pushed. Same commit but signed with the release key instead of my key.
<rburton>
thanks halstead
brrm has joined #yocto
frieder has joined #yocto
mckoan is now known as mckoan|away
Guest65 has joined #yocto
bhstalel has quit [Ping timeout: 245 seconds]
frieder has quit [Remote host closed the connection]
goliath has joined #yocto
Guest65 has quit [Quit: Client closed]
Kubu_work has quit [Quit: Leaving.]
bhstalel has joined #yocto
bhstalel has quit [Quit: Client closed]
Guest67 has joined #yocto
Guest67 has quit [Client Quit]
sgw has quit [Ping timeout: 255 seconds]
ptsneves has quit [Ping timeout: 252 seconds]
Chaser has joined #yocto
goliath has quit [Quit: SIGSEGV]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Circuitsoft has joined #yocto
rohieb has quit [Quit: ...yo ho ho and a bottle of rum]
sgw has joined #yocto
mrnuke has quit [Ping timeout: 246 seconds]
rohieb has joined #yocto
mrnuke has joined #yocto
Chaser has quit [Quit: Chaser]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<fray>
trying to build master on a recent 22.04 install.. but I'm getting an error that knotty can't run because curses is missing.. indeed if I run python3 then manually do "import curses", I get an error that _curses is missing, but can't figure out what I don't have installed
<fray>
anyone know what i might be missing?
roussinm has quit [Remote host closed the connection]
<rob_w>
sudo apt-get install libncurses-dev fray
<rob_w>
thats for generla curses dev package
<fray>
ok, I thought it was there, but I'll check again
<rob_w>
if your missing host pyhton stuff , check pip3 or such for its curses packages
<fray>
it was definitely missing, but python still can't import curses
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<fray>
I figured it out..
<fray>
whoever installed this put a custom (and of course _BROKEN_ version in /usr/local
<fray>
so I'd been fighting that for the past 45 minutes..
<rob_w>
good catch . Ride on !
<khem>
fray: I thought we poison host paths now a days so how does it find stuff from /usr/local I wonder
<fray>
so bitbake tried to run /usr/bin/env python3 -- which came from /usr/local/bin
tlwoerner_ has joined #yocto
tlwoerner has quit [Ping timeout: 260 seconds]
<fray>
I can explain why I saw the failure, but can't explain why the person who built the image felt the need to install a broken copy of python3 in /usr/local/bin
<khem>
hmmm, maybe we should send a note when /usr/local paths are used since it could mean trouble and does not comply with TESTED_DISTROS construct
<fray>
there are cases where PATH could be something specific, i.e. when a buildtools tarball is used.. but I doubt that gets 'directly' installed into /usr/local..
<fray>
I'd say the call to oe-init-build-env would be the place to check and warn
rob_w has quit [Quit: Leaving]
radanter has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 258 seconds]
Vonter has joined #yocto
alessioigor has quit [Remote host closed the connection]
tlwoerner_ has quit [Ping timeout: 260 seconds]
mvlad has quit [Remote host closed the connection]
Kubu_work has joined #yocto
Kubu_work has quit [Client Quit]
c_sutton has quit [Ping timeout: 255 seconds]
silbe has quit [Ping timeout: 264 seconds]
c_sutton has joined #yocto
silbe has joined #yocto
brazuca has joined #yocto
tlwoerner has joined #yocto
c_sutton has quit [Ping timeout: 258 seconds]
c_sutton has joined #yocto
florian_kc has joined #yocto
c_sutton_ has joined #yocto
c_sutton has quit [Read error: Connection reset by peer]
brazuca has quit [Quit: Client closed]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Estrella__ has joined #yocto
Estrella_ has quit [Ping timeout: 255 seconds]
Estrella__ has quit [Read error: Connection reset by peer]