wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
tlwoerner has joined #yocto
goliath has joined #yocto
Dracos-Carazza_ is now known as Dracos-Carazza
enok has joined #yocto
sakman has quit [Quit: Leaving]
rob_w has joined #yocto
alessio has joined #yocto
Zosma has joined #yocto
mckoan|away is now known as mckoan
leon-anavi has joined #yocto
rfuentess has joined #yocto
Kubu_work has joined #yocto
frieder has joined #yocto
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 246 seconds]
alessio has quit [Quit: alessio]
alessio has joined #yocto
alessio has quit [Read error: Connection reset by peer]
alessio has joined #yocto
zeemate has joined #yocto
Guest76 has joined #yocto
bhstalel has joined #yocto
eduter has joined #yocto
frgo has joined #yocto
<eduter>
Hi. I am facing an error where a package is duplicated, meaning that has been added twice to the PACKAGES list.
<eduter>
Error message i get form the Yocto build: ERROR: firmware-nxp-wifi-1.1-r0 do_package: QA Issue: firmware-nxp-wifi-nxpiw610-sdio is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]
<eduter>
I investigated and I can see that it is actually added from at least two different external static layers that I am using in my Yocto build system:
<eduter>
Is this an error? Can someone please let me know if this could be an issue on my end or on the Yocto end?
frgo_ has quit [Read error: Connection reset by peer]
<eduter>
Those layers are not my custom layer, that is why I am asking if this is something to report to the Yocto project or if I may be doing something wrong on my side.
florian has joined #yocto
<eduter>
I am aiming to build up base on LTS "scarthgap". I can see that the "meta-nxp" layer has this "firmware-nxp-wifi..." recipe present in "scarthgap" branch, which it was not present in "kirkstone". On the other hand, the "firmware-nxp-wifi..." recipe has been present since "kirkstone" branch for meta-freescale layer.
<mcfrisk>
eduter: these layers are from NXP not yocto community. You can fork the layers and amend them with fixes to issues like this, or if you know that one of the files is not needed in your builds, BBMASK the file away with path matching it
<LetoThe2nd>
Yo dudx
<eduter>
mcfrisk thanks a lot. I just got the tip about masking from googling. I will go down for that just to try to move forward. NXP is a private vendor, you have a point... sorry about that. It is not Yocto project responsability (y) (y)
<eduter>
thanks for the tip about masking, that is why I was looking for to be able to continue making progress. Thanks!
<bhstalel>
LetoThe2nd did you receive my question regarding the Yocto Speaker badges for the latest summit ?
<LetoThe2nd>
bhstalel: yup, and they should have been assigned right after the last summit. Sounds like you didn't get a notification? Can you check your badge account?
<mcfrisk>
eduter: if you carefully review the changes and recipes you need from each layer, and then BBMASK all the rest away, it is possible to do upstream yocto layer version updates while keeping an old BSP layer working and providing needed bootloader, kernel, drivers etc. I've done this multiple times. It's about reducing layers and their dependencies to bare minimum.
<mcfrisk>
that is, the BSP layer provider, e.g. HW/SoC provider, does not dictate the yocto version which you use for the general purpose SW stack which includes the cross compiler
alessio has quit [Read error: Connection reset by peer]
<bhstalel>
LetoThe2nd I am checking ...
<bhstalel>
Got it, thansk
<bhstalel>
thanks*
savolla has joined #yocto
<LetoThe2nd>
bhstalel: NP
<eduter>
mcfrisk thanks for the info. I am taking my time to diggest it. So my understanding of what you are telling me to keep in mind is that, upgrading Yocto-layers in my Yocto build system to "scarthgap" LTS, does not mean that I need to upgrade my "HARDWARE BSP private vendor" layers to the same. I can just mask anything I may not need to keep the
<eduter>
functionality to the minimum possible. I understand the tip and I will keep it in mind. At the moment I have to admit that I am just trying to upgrade everything to "scarthgap", as that was the general purpose of the task I was given. While I am just trying to make progress and successfully upgrade all branches from all layers to the "scarthgap",
<eduter>
as I increase my knowledge on this project and BSP, etc. I will keep in mind the advice you are giving me. Thanks :-)
<mcfrisk>
updating everything is the best case. Doing the update for high level SW stack, or preparing for the next, don't wayt for the BSP vendor to provide their support first...
<mcfrisk>
some changes are needed to compile BSP layers, e.g. for bitbake to parse them, and some adaptations due to changes in e.g. kernel.bbclass, but for the rest, including kernel major version changes. You can just wait but move on for the reset of the SW stack and especially open source layers
<eduter>
mcfrisk got you. Ok. I will updating everything if doable, that is the idea scenario for moving from LTS to LTS, for example, I am trying to do for my task. I will not wait for BSP private vendor to support... I know... that may be more tedious.
<eduter>
mcfrisk Yes ok. I will aim for updating the open source layers to the next LTS. And for the vendors if I can fantastic, otherwise, I can always "mask" or basically choose the bits that I need... instead of waiting for them to provide me with the support I need.
<Zosma>
I'm unsure how to get this patched back upstream without breaking again what the author wanted to fix.
<yocton>
Zosma: Can't the azure fetcher use a .netrc file? As far as I understood the strategy here, we try to avoid handling authentication data as much as possible in Yocto recipes/confs/...
<Zosma>
Furthermore, isn't it weird that *any* query string gets discarded, be it authentication or not? With the commit I mentioned it seems that I can't even add a '?option=value' if some API would need it.
prabhakalad has quit [Ping timeout: 272 seconds]
prabhakalad has joined #yocto
eduter has quit [Quit: Client closed]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #yocto
paulg has quit [Ping timeout: 252 seconds]
paulg has joined #yocto
eduter has joined #yocto
jbo_ has joined #yocto
jbo has quit [Ping timeout: 260 seconds]
eduter has quit [Quit: Client closed]
eduter has joined #yocto
eduter has quit [Ping timeout: 240 seconds]
eduter has joined #yocto
GillesM has joined #yocto
GillesM has quit [Remote host closed the connection]
GNUmoon has quit [Ping timeout: 264 seconds]
enok has joined #yocto
GNUmoon has joined #yocto
jbo_ is now known as jbo
enok has quit [Ping timeout: 265 seconds]
florian_kc has joined #yocto
Guest61 has joined #yocto
ablu has quit [Ping timeout: 252 seconds]
Guest61 is now known as Brox
<yocton>
Zosma: Sorry, we do not use Azure here, I can't tell what does/doesn't work and how :/
ablu has joined #yocto
enok has joined #yocto
enok has quit [Ping timeout: 252 seconds]
<Zosma>
yocton: no worries, appreciate your response!
eduter7 has joined #yocto
<rburton>
Zosma: file a bug - more complete url passing might work. or we need a azure fetcher that can add custom logic.
eduter has quit [Ping timeout: 240 seconds]
<Zosma>
rburton: aight, will do so, thanks.
sakoman has quit [Ping timeout: 268 seconds]
sakoman has joined #yocto
cyxae has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
eduter7 has quit [Quit: Client closed]
alessio has quit [Quit: alessio]
enok has joined #yocto
goliath has quit [Quit: SIGSEGV]
<fullstop>
I am using scarthgap and generating multiple machine images in the same tree. It consistently messes up with the do_create_spdx task when I switch between machines. I must cleansstate systemd and rebuild the image.
rob_w has quit [Remote host closed the connection]
enok has quit [Quit: enok]
enok71 has joined #yocto
enok71 has quit [Ping timeout: 246 seconds]
<rburton>
fullstop: file a bug with a reproducer please
jerrycash3 has quit [Read error: Connection reset by peer]
<rburton>
if python says dict iterator order is insertion order, just _how_ horrible is FOO, BAR = oeqa.utils.commands.get_bb_var(['FOO', 'BAR']).values()
<rburton>
erm, get_bb_vars obviously
Brox has quit [Quit: Client closed]
Articulus has quit [Quit: Leaving]
<khem>
rburton: dicts do preserve insertion order in newer pythons but I dont know what get_bb_var is doing w.r.t insertion is it creating a dictionary internally ?
rfuentess has quit [Remote host closed the connection]
<khem>
FOO = mydict['FOO']
<khem>
and same for BAR might ensure the order
<rburton>
yeah thats tedious though :)
frieder has quit [Remote host closed the connection]
florian_kc has joined #yocto
goliath has joined #yocto
leon-anavi has quit [Quit: Leaving]
mckoan is now known as mckoan|away
micka| has joined #yocto
micka has quit [Ping timeout: 272 seconds]
micka| is now known as micka
savolla has quit [Quit: WeeChat 4.4.3]
bhstalel has quit [Quit: Client closed]
enok has joined #yocto
Guest76 has quit [Ping timeout: 240 seconds]
enok has quit [Ping timeout: 245 seconds]
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
<tlwoerner>
rburton: i haven't sent my wic patch yet. i've updated the issue with my findings, how to reproduce, explain how i've fixed the issue, and demonstration of it fixed
<tlwoerner>
rburton: i'm running the wic and wic2 self tests and looking at adding a new test for this case
enok has joined #yocto
florian_kc has quit [Ping timeout: 248 seconds]
enok has quit [Ping timeout: 260 seconds]
florian_kc has joined #yocto
skandigraun has joined #yocto
<khem>
vmeson:can you reach out to Changqing Li and report this build failure - https://errors.yoctoproject.org/Errors/Details/851668/ with mariadb 11.4.5 upgrade I see the patch on lore.kernel.org but not in my inbox, mysterious world of emails
skandigraun has quit [Ping timeout: 240 seconds]
enok has joined #yocto
<gmorell>
r
eduter7 has joined #yocto
GillesM has joined #yocto
enok has quit [Quit: enok]
enok has joined #yocto
Kubu_work has quit [Quit: Leaving.]
druppy has joined #yocto
dankm has quit [Remote host closed the connection]
dankm has joined #yocto
druppy has quit [Ping timeout: 245 seconds]
GillesM has quit [Remote host closed the connection]
GillesM has joined #yocto
GillesM has quit [Remote host closed the connection]
GillesM has joined #yocto
eduter7 has quit [Quit: Client closed]
GillesMM has joined #yocto
GillesMM has quit [Remote host closed the connection]
Kubu_work has joined #yocto
GillesM has quit [Remote host closed the connection]
<vmeson>
khem: done, no the list and CCed you.
GillesM has joined #yocto
<vmeson>
*on the list
GillesM has quit [Remote host closed the connection]
sakman has joined #yocto
GillesM has joined #yocto
druppy has joined #yocto
GillesM has quit [Client Quit]
enok has quit [Ping timeout: 245 seconds]
<khem>
thanks, I have replied with a potential fix to try out
<JPEW>
RP: I'm not seeing any tests for the python module parsing in bitbake... can I just not find them or do they not exist?
<RP>
JPEW: we may not have any :(
<JPEW>
RP: K, just checking
goliath has quit [Quit: SIGSEGV]
<khem>
RP:clang merge and mesa fixes have conflicts, I am thinking of rebasing on top of mesa fixes, so sequence it mesa and than clang probably, I see value in having mesa fixes first so I have one more test for the merge
GillesM has joined #yocto
GillesM has quit [Client Quit]
druppy has quit [Ping timeout: 260 seconds]
<RP>
khem: ok, I had reported the clang issue to Dimitry and I think he was working on things. Are you ok with what the series does?
florian_kc has quit [Ping timeout: 265 seconds]
GNUmoon has quit [Ping timeout: 264 seconds]
GNUmoon has joined #yocto
<khem>
ideally I would have merged both together
<khem>
because some of the work will be undone by this change especially the meta-clang patches which are proposed to get going with the set proposed for work