frgo has quit [Read error: Connection reset by peer]
frgo_ has joined #yocto
dgriego has quit [Ping timeout: 248 seconds]
dgriego has joined #yocto
Articulus has joined #yocto
qschulz has quit [Remote host closed the connection]
<wmills_>
@khem: Thanks!
qschulz has joined #yocto
<tlwoerner>
khem: ld: error: unrecognized value '-z gcs-compliant=all'
<tlwoerner>
do i need to use master-next or something?
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
ajfriesen1642 has joined #yocto
ajfriesen164 has quit [Ping timeout: 252 seconds]
ajfriesen1642 is now known as ajfriesen164
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Chaser has joined #yocto
frgo_ has quit [Remote host closed the connection]
frgo has joined #yocto
Chaser has quit [Ping timeout: 248 seconds]
sakoman has quit [Ping timeout: 260 seconds]
sakoman has joined #yocto
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
<khem>
hmm ok
<khem>
tlwoerner: try with -Wl,-z,gcs-report-dynamic=none
dankm has quit [Ping timeout: 252 seconds]
dankm has joined #yocto
frgo has quit [Ping timeout: 260 seconds]
drkhsh has quit [Ping timeout: 248 seconds]
drkhsh has joined #yocto
OnkelUlla has quit [Read error: Connection reset by peer]
OnkelUlla has joined #yocto
ablu has quit [Ping timeout: 276 seconds]
Articulus has quit [Quit: Leaving]
ablu has joined #yocto
frgo has joined #yocto
alessio has joined #yocto
frgo has quit [Ping timeout: 248 seconds]
goliath has joined #yocto
ptsneves has quit [Ping timeout: 276 seconds]
frieder has joined #yocto
Kubu_work has quit [Quit: Leaving.]
frgo has joined #yocto
PeterM has joined #yocto
zeemate has joined #yocto
florian has joined #yocto
rfuentess has joined #yocto
enok has joined #yocto
Kubu_work has joined #yocto
iokill has joined #yocto
ptsneves has joined #yocto
berton_ has joined #yocto
berton_ has quit [Client Quit]
dmoseley has quit [Ping timeout: 265 seconds]
dmoseley_ has joined #yocto
florian has quit [Ping timeout: 248 seconds]
leon-anavi has joined #yocto
mbulut has joined #yocto
berton has joined #yocto
enok has quit [Ping timeout: 252 seconds]
florian has joined #yocto
<qschulz>
tlwoerner: got a Radxa Rock by any chance? I have a few patches to maybe make meta-rockchip build a wic image but I cannot test it
enok has joined #yocto
mbulut has quit [Remote host closed the connection]
ptsneves has quit [Ping timeout: 245 seconds]
florian_kc has joined #yocto
CrazyGecko3 has joined #yocto
mckoan|away is now known as mckoan
davidinux has quit [Ping timeout: 245 seconds]
lowvoltage has quit [Ping timeout: 252 seconds]
CrazyGecko has quit [Ping timeout: 252 seconds]
CrazyGecko3 is now known as CrazyGecko
pidge has quit [Ping timeout: 248 seconds]
lowvoltage has joined #yocto
pidge has joined #yocto
davidinux has joined #yocto
vthor has quit [Excess Flood]
enok has quit [Quit: enok]
enok71 has joined #yocto
wicki8 has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
kilobyte_ch has quit [Ping timeout: 244 seconds]
enok71 is now known as enok
wicki has quit [Ping timeout: 272 seconds]
wicki8 is now known as wicki
florian_kc has quit [Read error: Connection reset by peer]
<qschulz>
I'm wondering if we shouldn't set an override for aarch32 and aarch64 architectures for WKS_FILE_DEPENDS_BOOTLOADERS to virtual/bootloader by default?
mbulut has quit [Remote host closed the connection]
enok71 has joined #yocto
enok has quit [Read error: Connection reset by peer]
enok71 is now known as enok
<RP>
qschulz: there is a patch from mcfrisk doing that, I think it just needed a tweak
enok71 has joined #yocto
enok has quit [Read error: Connection reset by peer]
enok71 is now known as enok
enok71 has joined #yocto
enok has quit [Read error: Connection reset by peer]
enok71 is now known as enok
enok has quit [Quit: enok]
enok has joined #yocto
<mcfrisk>
qschulz: yes, I need to get back to those patches but they are coming. checking latest kernel changes currently which are related to my patches, somewhat. everything depends on everything :/
<mcfrisk>
qschulz: after some builds/rebuilds wic images can be without bootloader binaries due to this missing dependency, thus the other wic patches are also important..
<qschulz>
is systemd-boot REALLY the most popular option (and supported) for aarch64/aarch32 platforms?
<rburton>
qschulz: its better than grub :)
<qschulz>
well, you have U-Boot and Barebox too :)
enok has quit [Changing host]
enok has joined #yocto
<qschulz>
or am I misunderstanding what WKS_FILE_DEPENDS_BOOTLOADERS should contain?
enok has quit [Quit: enok]
enok has joined #yocto
<rburton>
i thought that variable was just "all the choices" because at that point you can't know what wic will want
<qschulz>
rburton: mmmm, we maybe do things different here in meta-rockchip (and possibly not correctly, who knows :) )
<qschulz>
because we set those wic variables from the machine conf file
<rburton>
ask tlwoerner what the intention is :)
<rburton>
maybe machines should override the defaults
<qschulz>
which happens to be parsed before the variable is hard-set by the bbclass
<qschulz>
the intention is not needing to set the variables from all image recipes for a board
<qschulz>
otherwise we'd also need to have a bbappend for all images from e.g. poky to generate a flashable image
<rburton>
set with overrides in your machine config?
florian_kc has quit [Ping timeout: 248 seconds]
florian_kc has joined #yocto
xmn has quit [Quit: ZZZzzz…]
florian_kc has quit [Read error: Connection reset by peer]
<mcfrisk>
well default u-boot upstrea configs will build UEFI support, and then it's either kernel or grub or systemd-boot as UEFI app. wic config decides which but the dependency to build them needs to be there. machine should set default and images should be able to override
prabhakalad has quit [Ping timeout: 244 seconds]
prabhakalad has joined #yocto
alessio has quit [Quit: alessio]
chep has quit [Ping timeout: 268 seconds]
<qschulz>
the image yes, not the bbclass
<qschulz>
where do you see "default upstream U-Boot configs will build UEFI support" ? each board has its own defconfig, where EFI could be enabled
<mcfrisk>
the configs in u-boot upstream
<mcfrisk>
I wish we could use EFI_PROVIDER for DEPENDS but it doesn't work atm
<qschulz>
"the configs in u-boot upstream" ?
<mcfrisk>
the defconfigs there for various boards
<qschulz>
yes? they may have UEFI there, and they may not
<qschulz>
there is no "default"
<qschulz>
aside from the default in Kconfig
<qschulz>
but I think the fundamental misunderstanding is that WKS_FILE_DEPENDS_BOOTLOADERS is not for the bootloader recipe
<qschulz>
it's for userspace tools interacting with the bootloader or whatever
<qschulz>
(and to be clear: *my* fundamental misunderstanding)
<mcfrisk>
there are too many bootloaders, too many stages and each claiming to be "the"
<qschulz>
isn't it why we have virtual/bootloader?
<mcfrisk>
HW microcode -> vendor FSBL -> security bits like bl31, optee, tf-a etc -> u-boot/edk2 -> kernel or boot menu tool like grub/systemd-boot -> initrd..
<mcfrisk>
which one of those is virtual/bootloader? to me it's just u-boot, edk2 or ovmf (edk2 really)
<mcfrisk>
EFI_LOADER is either grub or systemd-boot
<mcfrisk>
in some setups boot can be directly from HW microcode -> u-boot -> kernel
<qschulz>
you do still have u-boot in that chain though
<qschulz>
which is virtual/bootloaders
<qschulz>
-s
<qschulz>
some platforms (like Rockchip) have (currently) tf-a and op-tee in U-Boot directly, so that's a good enough dependency (for that architecture)
<qschulz>
s/architecture/vendor/
<qschulz>
but I think this is not an important discussion as I believe we only want things consumed by the bootloader in WKS_FILE_DEPENDS_BOOTLOADERS?
<mcfrisk>
yes that's the meta-arm approach too, the setup between boards is quite distributed in various recipes which all need to be aligned with memory regions etc
<mcfrisk>
which level of bootloader :)
<mcfrisk>
to me it's the EFI_LOADER or kernel. "bootmenu" would be more descriptive, imo
<qschulz>
fair enough
<mcfrisk>
and even that's bad since u-boot can have a menu, EFI can have a menu, and then grub/systemd-boot too
<qschulz>
I can see grub being a bootloader too
<qschulz>
or whatever EFI application or whatever the proper name for that is :)
<mcfrisk>
yea
<mcfrisk>
and those can be chained in various ways..
<qschulz>
and I guess we could argue that the bootloader (pre-EFI) may be on a different storage medium than the one the wic image will be flashed too
<qschulz>
s/too/to/
<mcfrisk>
yes, or on the same medium, sdcard/mmc, which is handy when testing things, but then there is more uncontrolled code in other flash storage or HW..
<qschulz>
tlwoerner: forget about the Radxa Rock, the rockchip maintainer had one and it cannot boot upstream U-Boot because it needs special stuff to boot that somehow got broken over time :)
alessio has joined #yocto
alessio has quit [Remote host closed the connection]
<rburton>
so jonmason should be working on some better naming for all the different things that are 'bootloader'
<rburton>
qschulz mcfrisk ^
<qschulz>
rburton: it's always a question of perspective
<qschulz>
I had HW engineers tell me everyting software is a firmware
<rburton>
ha
<RP>
FWIW master-next has the pseudo "include" instead of "exclude" paths patches in
<rburton>
nice
<RP>
I'll run them through the AB and see how bad things look
<RP>
poky-tiny builds...
<RP>
It is 18 months since I touched them so I've forgotten enough to think about it again
<PeterM>
${WORKDIR}/pkgdata in PSEUDO_INCLUDE_PATHS looks suspicious as it will include ${WORKDIR}/pkgdata-sysroot which was previously in PSEUDO_IGNORE_PATHS
<RP>
PeterM: that is an interesting point. I wonder why I did that
PeterM has left #yocto [#yocto]
<mcfrisk>
should layers/recipes/bbclasses amend PSEUDO_INCLUDE_PATHS if their funky tools need it, or submit changes to oe-core?
<tlwoerner>
qschulz: yes, i do have a Radxa Rock (but reading further i see that's not important now)
<tlwoerner>
khem: is that a solution, or an investigation/work-around?
<mcfrisk>
tlwoerner: I tried that too but it failed for me. config step in systemd build failed to detect compiler etc properly. hmm..
<tlwoerner>
qschulz: i too questioned the patch you have referenced, which is why i questioned it
<tlwoerner>
(i.e. replied to it in email)
<tlwoerner>
mcfrisk: what MACHINE?
<mcfrisk>
genericarm64
<RP>
mcfrisk: wouldn't the classes/recipes that need it handle that?
cyxae has joined #yocto
<RP>
hmm, poky-tiny failed on debian11 after passing on debian12
enok71 has joined #yocto
enok has quit [Ping timeout: 252 seconds]
enok71 is now known as enok
<mcfrisk>
RP: ok then they need to move writes to WORKDIR or adjust PSEUDO_INCLUDE_PATHS, preferably former. sstate cache cleaning for affected recipes is needed since qa check for non-root files is run later
<RP>
mcfrisk: which location are the things you're thinking of using?
<mcfrisk>
RP: not sure yet. Just ran into issues with meta-arm recipes with my change so I suspect they may need tweaks for dtb/dtc etc tooling. I should find time to try master-next..
<RP>
anything building on debian11 breaks :/
ptsneves has joined #yocto
Chaser has joined #yocto
<sunkist>
Bitbake doesn't have a bit torrent fetcher. It would bring a nice performance boost for some large assets, so I thought about writing one. My biggest practical challenge is how to format the URL.
<sunkist>
A torrent file for an Ubuntu ISO is 263 KB, not easily encoded into a SRC_URI.
<rburton>
would be simple enough to just have the torrent file itself be a local file
<sunkist>
rburton: Yes, store the torrent file a local file in the recipe, then have a SRC_URI of torrent://localfile.torrent
<rburton>
pointing _at_ the remote torrent would be the obvious answer imho
<sunkist>
rburton: I'm trying to work out how I can disambiguate local and remote torrentfiles. That is, if the SRC_URI begins with http://, we know to do a wget fetch. But if it begins with torrent://, how do we know whether to do a local or an http fetch?
<qschulz>
random thought but maybe something similar to handling tarballs which you can compress or not? similar to patches that are fetched and then applied in a later stage?
<qschulz>
s/compress/decompress
ptsneves has quit [Ping timeout: 252 seconds]
<rburton>
torrent://releases.ubuntu.com/25.04/ubuntu-25.04-desktop-amd64.iso.torrent would be the same as torrent://releases.ubuntu.com/25.04/ubuntu-25.04-desktop-amd64.iso.torrent;protocol=https but with implicit protocol, so you could also do torrent://./foo;protocol=file
<rburton>
(same as the git fetcher)
Xagen has joined #yocto
<qschulz>
rburton: meh, you wouldn't benefit from the wget fetcher easily
<qschulz>
e.g. with authentication and all
<qschulz>
mmmm, but that remark would apply to the git fetcher too
<qschulz>
so I'll stop commenting now as I don't know what I'm talking about :)
<svuorela>
a
<svuorela>
woops
enok has quit [Quit: enok]
enok has joined #yocto
<sunkist>
rburton: the protocol=[file|http] seems a lot cleaner. If protocol is unspecified, the fetcher could infer the right behavior (if it smells like an https URL try that first)
<sunkist>
Then the SRC_URI[sha256sum] would be the hash of the .torrent file (because the torrent itself may deliver many files)
dgriego has quit [Quit: Bye]
alessio has joined #yocto
alessio has quit [Read error: Connection reset by peer]
<RP>
Looks like the question is around /dev, that I made rootfs work but not sdk or esdk
xmn has joined #yocto
alessio has joined #yocto
alessio has quit [Client Quit]
<mcfrisk>
tlwoerner: sorry, I was wrong, the last linker flag " -Wl,-z,gcs-report-dynamic=none" does work. "-Wl,-z,gcs-compliant=all" did not. will reply to list...
florian_kc has joined #yocto
frgo has quit [Remote host closed the connection]
<tlwoerner>
mcfrisk: ah good. my builds with genericarm64 were confirming the same thing (and i was wondering why mine succeeds when yours didn't, but all good now)
enok has quit [Remote host closed the connection]
enok has joined #yocto
<sunkist>
I assume using a pure python client like pybittorrent (MIT) is preferable to shelling out to `transmission'?
<rburton>
either works, a python client library is likely a better choice for integration/reliability
chep has joined #yocto
<qschulz>
pybittorrent last release was 2 and half years ago though there was some commit a year ago
frgo has joined #yocto
jerrycash has joined #yocto
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
frgo has quit [Ping timeout: 260 seconds]
frgo has joined #yocto
frgo has quit [Client Quit]
enok has quit [Ping timeout: 260 seconds]
enok has joined #yocto
<khem>
tlwoerner:I think it is a solution we can apply to systemd since its build is pedantic, I was thinking if we need it globally, but it seems we don't, default is to warn and thats ok unless a build system treats warnings as errors like systemd does
<rburton>
yeah its specific to systemd
<rburton>
i'm chasing the right people to get openssl patched to solve this at root too
<khem>
rburton: I think thats good.
<khem>
this problem will be in many other places to fix
<rburton>
well, the linker warning is correct. its dumb to enforce fatal-warnings.
<khem>
maybe look at world build for the gcs warnings from linker
<rburton>
the warnings will be everywhere, yes
<khem>
yeah its is right and it should be fixed, I am saying its not just libcrypto.so
<khem>
other places it might be happening too but its a warning by default so builds will not fail
<khem>
RP:I sent couple of patches which should help with clang image-size/compile-time situation
frieder has quit [Remote host closed the connection]
rfuentess has quit [Remote host closed the connection]
pidge_ has joined #yocto
pidge has quit [Ping timeout: 276 seconds]
pidge has joined #yocto
pidge_ has quit [Ping timeout: 268 seconds]
zeemate has quit [Ping timeout: 260 seconds]
sgw has quit [Quit: Leaving.]
florian has quit [Quit: Ex-Chat]
Kubu_work has quit [Quit: Leaving.]
Kubu_work has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
Kubu_work has quit [Ping timeout: 252 seconds]
mbulut has joined #yocto
mrpelotazo_ has quit [Quit: Hasta la vista!]
enok has quit [Read error: Connection reset by peer]
enok has joined #yocto
mbulut has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
mrpelotazo has joined #yocto
rcw has joined #yocto
nerdboy has quit [Remote host closed the connection]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
druppy has joined #yocto
leon-anavi has quit [Quit: Leaving]
ptsneves has joined #yocto
goliath has quit [Quit: SIGSEGV]
Chaser has joined #yocto
enok71 has joined #yocto
enok has quit [Ping timeout: 248 seconds]
enok71 is now known as enok
enok71 has joined #yocto
enok has quit [Ping timeout: 272 seconds]
enok71 is now known as enok
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Chaser has joined #yocto
Kubu_work has joined #yocto
PeterM has joined #yocto
druppy has quit [Ping timeout: 244 seconds]
PeterM has quit [Quit: Client closed]
berton has quit [Quit: Connection closed for inactivity]
rcw has quit [Quit: Client closed]
PeterM has joined #yocto
<tlwoerner>
d'oh, i should have added a bunch of CCs to that oecore patch for gcs
<tlwoerner>
thanks, rburton, for the patch description body :-)
<rburton>
ha
nerdboy has quit [Ping timeout: 260 seconds]
sgw has joined #yocto
nerdboy has joined #yocto
enok has quit [Quit: enok]
PeterM has quit [Quit: Client closed]
florian_kc has joined #yocto
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jerrycash2 has joined #yocto
jerrycash has quit [Ping timeout: 260 seconds]
eduter has joined #yocto
cyxae has quit [Quit: cyxae]
paulg_ has quit [Ping timeout: 276 seconds]
steelswords94361 has joined #yocto
sakoman has quit [Ping timeout: 252 seconds]
paulg_ has joined #yocto
sakoman has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Kubu_work has quit [Quit: Leaving.]
eduter has quit [Ping timeout: 240 seconds]
goliath has joined #yocto
zeemate has joined #yocto
Kubu_work has joined #yocto
<tlwoerner>
and thanks to khem for the actual flag