qschulz has quit [Remote host closed the connection]
Xogium has quit [Ping timeout: 276 seconds]
qschulz has joined #yocto
prabhakalad has quit [Ping timeout: 276 seconds]
prabhakalad has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
_whitelogger has joined #yocto
npcomp has joined #yocto
dvergatal has quit [Ping timeout: 252 seconds]
<khem>
debianutils is failing to fetch - ERROR: debianutils-native-5.22-r0 do_fetch: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'git://salsa.debian.org/debian/debianutils;protocol=https;branch=master;tag=debian/5.22')
Xogium has quit [Remote host closed the connection]
Xogium has joined #yocto
dmoseley_ has joined #yocto
dmoseley has quit [Ping timeout: 260 seconds]
Tyaku has quit [Quit: leaving]
Xogium has quit [Remote host closed the connection]
Xogium has joined #yocto
psi has joined #yocto
dmoseley_ has quit [Ping timeout: 244 seconds]
dmoseley has joined #yocto
dmoseley_ has joined #yocto
dmoseley has quit [Ping timeout: 272 seconds]
Kubu_work has joined #yocto
Kubu_work has quit [Client Quit]
Kubu_work has joined #yocto
davidinux has joined #yocto
florian_kc has joined #yocto
florian_kc is now known as florian
kpo_ has joined #yocto
kpo has quit [Ping timeout: 252 seconds]
kpo has joined #yocto
kpo_ has quit [Ping timeout: 276 seconds]
berton has joined #yocto
Articulus has quit [Quit: Leaving]
alessio has joined #yocto
MarcWeDLM has quit [Quit: Client closed]
ablu has quit [Ping timeout: 260 seconds]
ablu has joined #yocto
mansandersson86 has quit [Ping timeout: 276 seconds]
ptsneves has joined #yocto
PeterM has quit [Quit: Client closed]
sanbeam has joined #yocto
wooosaiiii has quit [Ping timeout: 276 seconds]
sanbeam9 has joined #yocto
sanbeam has quit [Ping timeout: 276 seconds]
sanbeam18 has joined #yocto
sanbeam9 has quit [Ping timeout: 260 seconds]
davidinux has quit [Ping timeout: 260 seconds]
mbulut has joined #yocto
zeddii has quit [Ping timeout: 265 seconds]
sanbeam18 has quit [Remote host closed the connection]
sanbeam has joined #yocto
MarcWeDLM has joined #yocto
sanbeam has quit [Remote host closed the connection]
MarcWeDLM has quit [Client Quit]
MarcWeDLM has joined #yocto
ptsneves has quit [Ping timeout: 248 seconds]
PeterM has joined #yocto
florian has quit [Ping timeout: 276 seconds]
sanbeam has joined #yocto
florian has joined #yocto
Kubu_work has quit [Quit: Leaving.]
psi has quit [Quit: Client closed]
Kubu_work has joined #yocto
Kubu_work has quit [Ping timeout: 265 seconds]
mansandersson86 has joined #yocto
Kubu_work has joined #yocto
sanbeam has quit [Ping timeout: 276 seconds]
cyxae has joined #yocto
davidinux has joined #yocto
vvn has joined #yocto
Xagen has joined #yocto
sakman has joined #yocto
goliath has quit [Quit: SIGSEGV]
davidinux has quit [Ping timeout: 244 seconds]
<JPEW>
RP: r.e. PURLs: Does bitbake know the layer that a recipe (.bb file) comes from? The current proposal is to add the layer name to the PURL and I'd hate to say OK to that and then not be able to implement it
PeterM has quit [Quit: Client closed]
<RP>
JPEW: it didn't used to but we have layer-${FILE_LAYERNAME} in OVERRIDES
PeterM has joined #yocto
alessio has quit [Quit: alessio]
<PeterM>
Should be doable via matching FILE against BBFILE_PATTERN_*:
frieder has quit [Remote host closed the connection]
sudip_ is now known as sudip
fray has joined #yocto
<JPEW>
I'm got a PoC for implementing the PURL standard being proposed by upstream PURL for Yocto recipes, if anyone wants to take a look and see what they think: https://git.yoctoproject.org/poky-contrib/log/?h=jpew/purls
<KanjiMonster>
JPEW: The PURL stuff seems confusing, sometimes its package manager based (apk, rpm), sometimes distro(?) based. OpenWrt recently switched from opkg to apk as their package manager, should they now use apk instead of openwrt?
<JPEW>
KanjiMonster: Yes, it's complicated
<KanjiMonster>
Actually that question is answered by the docs "The namespace is the vendor such as alpine or openwrt. It is not case sensitive and must be lowercased.". So openwrt with apk isn't openwrt anymore, but apk with openwrt namespace
<KanjiMonster>
JPEW: but I guess you would use two, a yocto: thingy to describe the package recipe source, and a deb|rpm|opkg:/ thingy to describe the binary package generated from it?
druppy has joined #yocto
dvergatal has quit [Ping timeout: 268 seconds]
<JPEW>
KanjiMonster: Possibly
<JPEW>
We can't provide the deb|rpm|opkg PURL though, because we don't know where they will be published (if at all)
<JPEW>
But we're working with upstream PURL to define a yocto PURL we can specify
dvergatal has joined #yocto
* vmeson
grumbles about the new kids, using PURL rather than PKGURL as their name, to avoid verbal confusion with the Perl language! GOML!
<KanjiMonster>
JPEW: deb/apk/rpm don't specify/require a location either, just a distro name (namespace). AFAIU you can specify one via repository_url though (but that is optional)
<JPEW>
if you don't specify, it has a wrong default
<KanjiMonster>
JPEW: all those say there is no default
<AdrianF>
KanjiMonster: Why do you think that the package format is important? At least in theory it should be possible to switch from rpm to deb and get the same SBOM and purl. The package format is not relevant from my point of view.
<AdrianF>
KanjiMonstaer: I also think in context of Yocto, referring to binary packages without specifying all the details of DISTRO and MACHINE is kind of odd. It reminds me to all the questions like, can I use Yocto to build a Debian package and install it on Debian?
berton has quit [Quit: Connection closed for inactivity]
cyxae has quit [Quit: cyxae]
mbulut has quit [Remote host closed the connection]
mbulut has joined #yocto
<KanjiMonster>
AdrianF: at least AFAICT deb, rpm etc describe packages in that format, so by that extensions I would also attempt use them to describe binary packages generated by Yocto
<khem>
yocto's source of truth is metadata + sourcecode and binary output packages are just a distribution mechanism, I can understand for binary distros the package management is source of truth
<khem>
how do we represent this fact in PURLs ?
<KanjiMonster>
But if I do a binary distribution with package feeds, I would want to describe the (binary) packages right?
<JPEW>
KanjiMonster: Maybe; I'm not enough of a PURL expert to know if that's useful or not
<KanjiMonster>
I'm not either
<khem>
KanjiMonster: yes you might want to if you maintain a binary distro which is built with yocto but thats one usecase of yocto
<khem>
while for other distros thats the only usecase
<RP>
vmeson: what is perl? :)
<khem>
Practically End of Life Programming Language :)
<khem>
I have peicemealed couple of patches along the way to ML, but I will prepare v1 for submitting soon, a-quick looks good too, so no regressions
* khem
wonders how to pronounce Wrynose, is it like 'Dry-Nose' or 'Frey-Nuss" I would guess the latter
<vmeson>
RP, khem: lol but somewhat accurate
Kubu_work has quit [Quit: Leaving.]
<khem>
so more clang - Clang is needed in Python 3.14 due to the introduction of a new tail-call interpreter.
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<khem>
Clang 19 and newer versions are known to provide the necessary support for these features, making it a requirement for utilizing the new interpreter. While it's possible to compile Python 3.14 with other compilers, the tail-call interpreter will only be activated when using Clang 19 or newer
<khem>
So Python Pi ( 3.14 ) won't be sweet :)
mbulut has quit [Ping timeout: 245 seconds]
dvergatal has quit [Remote host closed the connection]
druppy has quit [Ping timeout: 260 seconds]
dvergatal has joined #yocto
druppy has joined #yocto
druppy has quit [Ping timeout: 276 seconds]
<RP>
khem: very cool!
<RP>
(the qemuarm world build, not py 3.14)
<khem>
RP: yeah, and I think we can now extend it toolchain-<any-COMPILER> in future
<khem>
by adding COMPILER.bbclass
<khem>
I have rebased on top of master-next and will see where it stands tonight
dvergatal has quit [Read error: Connection reset by peer]
<khem>
re. python 3.14 there was some high expectations from tail-call interpreter but gains are 5-7% overall which is not bad but not like 30% as some were hoping for
<khem>
in OE we are so much python dependent that we will take 5-7% happily