Guest3914 has quit [Killed (silver.libera.chat (Nickname regained by services))]
sotaover1ide is now known as sotaoverride
ctraven has joined #yocto
mjm has joined #yocto
Dracos-Carazza has quit [Quit: ZNC 1.9.0 - https://znc.in]
Dracos-Carazza has joined #yocto
paulg has quit [Read error: Connection reset by peer]
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
ctraven has quit [Ping timeout: 268 seconds]
roussinm has quit [Ping timeout: 268 seconds]
ctraven has joined #yocto
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
wooosaiiii has quit [Remote host closed the connection]
ctraven has quit [Ping timeout: 268 seconds]
ctraven has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
alessioigor has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
Kubu_work has joined #yocto
ctraven has quit [Ping timeout: 260 seconds]
ctraven has joined #yocto
jmd has quit [Remote host closed the connection]
alperak has joined #yocto
jmd has joined #yocto
jmd has quit [Remote host closed the connection]
rob_w has joined #yocto
leon-anavi has joined #yocto
rfuentess has joined #yocto
belsirk has joined #yocto
wooosaiiii has joined #yocto
rfuentess has quit [Ping timeout: 268 seconds]
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
dkc has quit [Ping timeout: 268 seconds]
<khem>
RP: sent a fix for gcc which should fix the problem, you might try both python and gcc patch together and see how it goes
belsirk is now known as rfuentess
mbulut has joined #yocto
ehussain has joined #yocto
dkc has joined #yocto
florian has joined #yocto
Jones42 has joined #yocto
Saur_Home69 has joined #yocto
Saur_Home5 has quit [Ping timeout: 250 seconds]
florian_kc has joined #yocto
BhsTalel has joined #yocto
Jones42_ has joined #yocto
xmn has quit [Quit: ZZZzzz…]
Jones42 has quit [Ping timeout: 240 seconds]
Jones42_ is now known as Jones42
rob_w has quit [Quit: Leaving]
<RP>
khem: I'm afraid I know it won't work just reading the patch :(
florian_kc has quit [Ping timeout: 268 seconds]
ehussain has quit [Ping timeout: 268 seconds]
Kubu_work has quit [Quit: Leaving.]
ehussain has joined #yocto
<KanjiMonster>
I'm having a hard time coming up with a way to setup a tree (using repo) with checking out poky and supplying a .templateconf to point to a different template without forking poky or causing uncommited git changes present
<Xogium>
KanjiMonster: I mean, poky is a reference distro. You shouldn't be using it to make your own things, probably
<Xogium>
using oe-core might avoid the problems you have ?
<KanjiMonster>
unfortunately not, oe-core also ships a (different) .templateconfig
<rburton>
KanjiMonster: can you not put the templateconf in your layer
<KanjiMonster>
what I'm attempting is to not force users to set TEMPLATECONF, but rather use the one for our "distro" by default
<Crofton>
But that means changing the default configs, and that is what your problem is ....
<KanjiMonster>
for kirkstone we ship a semi-pre-poulated build dir with .sample files and a templateconf.cfg, so running oe-init-build-env build-our-distro automagically works
<rburton>
your layer can have its own oe-init-build-env script
<KanjiMonster>
that's what I'm currently trying to avoid, I want to keep things working as they currently do, as these are ingrained in docs and CI etc
tlwoerner has quit [Read error: Connection reset by peer]
tlwoerner has joined #yocto
davidinux has quit [Ping timeout: 246 seconds]
davidinux has joined #yocto
ehussain has quit [Quit: ehussain]
florian has quit [Ping timeout: 268 seconds]
jmiehe has joined #yocto
Kubu_work has joined #yocto
florian_kc has joined #yocto
lexano has joined #yocto
<tgamblin>
rburton: do you know if there's a better license for public domain than meta/files/common-licenses/PD?
<tgamblin>
Unlicense?
enok has joined #yocto
<tgamblin>
I guess it'd be CC-PDDC
tlwoerner has quit [Ping timeout: 264 seconds]
tlwoerner has joined #yocto
enok has quit [Ping timeout: 240 seconds]
enok has joined #yocto
enok has quit [Client Quit]
enok has joined #yocto
Jones42_ has joined #yocto
florian has joined #yocto
Jones42 has quit [Ping timeout: 268 seconds]
xmn has joined #yocto
<rburton>
tgamblin: that's probably the closest
<rburton>
tgamblin: people who use 'public domain' should be shot into space
<tgamblin>
rburton: I put CC0-1.0 in at the end, since that's what's referenced in COPYING.txt
<rburton>
tgamblin: good rationale thanks
zpfvo has joined #yocto
Jones42_ has quit [Ping timeout: 240 seconds]
jmiehe has quit [Quit: jmiehe]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #yocto
phako_ has joined #yocto
<phako_>
hi. Does anyone happen to know what fixed CMake's FindPython picking up the host python? (I am on honister, seems to work fine on langdale)
<rburton>
there's a FIND_PATH assignment in cmake.bbclass
roussinm has joined #yocto
<phako_>
rburton do you mean OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM ?
<phako_>
or the filling of the *FIND_ROOT_PATH path in toolchain.cmake
GNUmoon2 has quit [Ping timeout: 260 seconds]
florian_kc has quit [Ping timeout: 272 seconds]
GNUmoon2 has joined #yocto
mulk has quit [Ping timeout: 264 seconds]
<rburton>
yes, those
mulk has joined #yocto
<phako_>
They seem to be identical between honister and langdale. Wonder if CMake fixed FindPython
<phako_>
They only differ in a comment. Well, screw it, I will hard-code python include paths and hope we can get rid of anything older than langdale ASAP
<Guest3738>
for some reason, CONVERSIONTYPES is missing enc as an option, inherit swupdate-enc clearly says "CONVERSIONTYPES += "enc"" and my image recipe inherits it
<vvn>
I have a shared docker volume mounted on /deploy and I set DEPLOY_DIR to a subfolder of it per project, e.g. /deploy/myproject, yet bitbake complains about overlapping files. What am I missing?
Jones42 has joined #yocto
<rburton>
vvn: without more context, its impossible to say
<rburton>
if files exist that bitbake didn't know about then it will complain
<vvn>
rburton: ha ok, indeed the file exists, but from the same build. Exactly as with an existing build (and DEPLOY_DIR set to TMPDIR/deploy)
<rburton>
_same tmpdir_ though?
<rburton>
does bitbake actually know about them?
<vvn>
hum no it's a fresh tmpdir indeed
<rburton>
if your goal is to just archive builds, it might be easier to do a build and then _if its is successful_ copy to the shared directory
<rburton>
otherwise you'll end up with partial builds in your shared deploy
<vvn>
I just set DEPLOY_DIR to an external folder so that I get serve them during development (but a subfolder per project)
<vvn>
rburton: ok so you're saying that I should keep the DEPLOY_DIR under TMPDIR, correct?
<rburton>
yeah i would
<vvn>
ok ok, being about to set a different value for DEPLOY_DIR* is confusing then
<JPEW>
RP: I realized the UNPACKDIR changes can simplify some of the SPDX code to capture source files; I sent an RFC patch set. Curious what you think
BhsTalel has quit [Quit: Client closed]
Jones42 has quit [Ping timeout: 256 seconds]
dgriego has quit [Quit: Computer going to sleep]
dgriego has joined #yocto
jmd has joined #yocto
vthor has joined #yocto
<RP>
JPEW: I was hoping to be able to make some simplifications like this. Should we do this in the fetcher though?
<phako_>
the missing magic seems to be "inherit python3native"
<RP>
doing a walk over all the files isn't ideal but...
<JPEW>
RP: I didn't time it, but it seems to be fast enough I didn't notice the difference. I think at this point the files are still "hot" in the FS cache, since they were just written
<JPEW>
SHould be profiled though to make sure
<JPEW>
RP: Like in fetcher.unpack() ?
<RP>
JPEW: right, everything should still be in the disk cache. Is SPDX doing this at a later point anyway?
<JPEW>
It's doing the silly thing of re-running do_unpack like archive.bbclass
<RP>
JPEW: or we expose a new API in the fetcher and call it after .unpack() ?
<RP>
JPEW: I was also thinking about writing out the SDE info from somewhere around here
<JPEW>
`fetcher.write_file_manifest(unpackdir, manifest_path, ....)` isn't really and different than the OE write_file_manifest(), other than that it lives in bitbake (which is fine if you think that's a better option)
<RP>
JPEW: you might need to persist the manifest info but we could do that alongside SDE
<JPEW>
RP: I don't think I need it persisted (for SPDX) anyway
<RP>
JPEW: I was just thinking we should perhaps keep the fetcher "ops" together
<RP>
JPEW: it means if you need to rebuild the SPDX data it would have to unpack all the source code
<JPEW>
Yes, that is already true (at least if you want the source file tracking, which is disabled by default)
<RP>
well, you might be able to avoid it...
<JPEW>
Right
<RP>
JPEW: I'm trying to think about this from multiple angles
<JPEW>
I'm not sure how to persist it though, would it need some... do_unpack_manifest task that is sstate?
<RP>
JPEW: merge with do_deploy_source_date_epoch
<JPEW>
mmm, ya, ok
<RP>
they're both "source info"
<RP>
as I've hinted at, I think these functions need rework anyway
<vvn>
rburton: do all your projects have some post-scripts to copy files around?
<rburton>
vvn: _our_ projects just use gitlab artifacts to save what we want to save
<rburton>
but i don't have the same use case as you i imagine
<vvn>
rburton: I have several build to do, all of them obviously use different revisions, etc. in the end I need to centralize the .wic* and .ipk files somewhere
<RP>
JPEW: we can do this incrementally, I'm just trying to share where I see things going. Your patch even as is seems an improvement
<JPEW>
RP: Ya, either way we'll need to write the manifest out in do_unpack; we can make it saved in sstate and simplify SDE (?)
<JPEW>
*saved in sstate and simplify SDE later(?)
<RP>
JPEW: we can't make unpack directly sstate since it doesn't restore the source
<JPEW>
Ya, for sure
vthor has quit [Ping timeout: 255 seconds]
<khem>
RP: that check is used in multiple places in GCC sources already, this patch does not introduce that check, so we might be hopig too much by using common compiler across glibc and musl systems
enok has quit [Ping timeout: 240 seconds]
cambrian_invader has joined #yocto
LocutusOfBorg has quit [Ping timeout: 260 seconds]
LocutusOfBorg has joined #yocto
goliath has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
Guest62 has joined #yocto
<Guest62>
Is it necessary to do an UNPACKDIR migration for B = ${WORKDIR}
Guest3738 has quit [Quit: Connection closed]
rfuentess has quit [Remote host closed the connection]
<rburton>
jonmason: Matter is lots of things, support for matter doesn't mean monitoring
ablu has quit [Ping timeout: 268 seconds]
ablu has joined #yocto
mbulut has quit [Ping timeout: 240 seconds]
ablu has quit [Ping timeout: 252 seconds]
<JPEW>
RP: I think maybe the problem with making it part of the fetcher is that I'm not sure making a manifest of a directory is specific to the fetcher; I could see the same function being used in other places. Maybe make it part of bb.utils?
<RP>
JPEW: we did already have some of this manifest generation added within the fetcher too. The piece which is missing from that manifest which people have wanted is the info of which files come from which srcuri entries
Kubu_work has quit [Quit: Leaving.]
<JPEW>
RP: BB_UNPACK_TRACER_CLASS ?
<RP>
JPEW: the tracer, yes. I was blanking on that word
alessioigor has quit [Quit: Client closed]
paulg has joined #yocto
<JPEW>
BB_UNPACK_TRACER_CLASS should probably be a list of classes I guess, and we'd have a class that appends to a manifest file each time it's called?
ablu has joined #yocto
ehussain has joined #yocto
<RP>
JPEW: maybe, or drop the "API" to it and just put some kind of manifest generation into the unpack code out the box
zpfvo has quit [Remote host closed the connection]
vthor has quit [Ping timeout: 246 seconds]
<khem>
RP: sent a v2 which makes the musl check in code istead of build time macro check
<khem>
I have checked that it works correctly for TCLIBC=musl and TCLIBC=glibc
dgriego has quit [Quit: Computer going to sleep]
dgriego has joined #yocto
paulg has quit [Read error: Connection reset by peer]
<tlwoerner>
so we still have to wait 2 weeks for workdir/unpackdir fixes for meta-arm? i see other patches getting into meta-arm master
ehussain has quit [Quit: ehussain]
sveinse has joined #yocto
<sveinse>
Is there still activity in this channel?
mischief has quit [Remote host closed the connection]
mischief2 has joined #yocto
<sveinse>
Is there something that can be done to rebuild the packages (ipk i my case)? I have a system which relies on sstate cache and I'm having problems with that e.g. the package gcc-*.ipk is missing in build/tmp despite it being rdepended on by packagegroup-core-buildessential.
<sveinse>
I suspect I'm lacking a step to rebuild the ipks
<khem>
being part of packagegroup wont be enough, unless the packagegroup is used in an image which is being built
<sveinse>
So bitbake packagegroup-core-buildessential is not enough, is that what you mean?
<sveinse>
I'm building lots of additional packages for a package repo. There are many packages that isn't included in images.
Saur_Home69 has quit [Quit: Client closed]
Saur_Home69 has joined #yocto
mischief2 has quit [Ping timeout: 256 seconds]
mischief has joined #yocto
<khem>
well generally ipks should be built for target and all its dependencies so it should work in general
<sveinse>
I just tested by removing "make" from sstate cache and rerun "bitbake packagegroup-core-buildessential". I verify that the package is built, but for some reason I don't seem to get a package generated
<sveinse>
bitbake is happy and saying the build target is complete
<sveinse>
aha. Now I run "bitbake make" and now I get the ipk target running. So I think you're right khem, only bitbaking the packagegroup is not enough
<khem>
package groups are meta packages they have no existence of their own otherwise
<sveinse>
No, that's fine. But I need all the ipks that the packagegroup depends on
<khem>
you can create an image or you can do bitbake world if you want to offer a large set of binary packages
<sveinse>
Hmm. I want neither. World is too big, and I don't need to spend efforts building an image I don't want.
rfs613 has quit [Ping timeout: 260 seconds]
<sveinse>
But I can investigate how world pulls everything.
<sveinse>
Suspect its hard coded
rfs613 has joined #yocto
alperak has quit [Quit: Connection closed for inactivity]
dkl has quit [Quit: %quit%]
Saur_Home69 has quit [Quit: Client closed]
Saur_Home69 has joined #yocto
dkl has joined #yocto
mischief has quit [Ping timeout: 256 seconds]
vthor has joined #yocto
mischief has joined #yocto
Saur_Home69 has quit [Quit: Client closed]
Saur_Home69 has joined #yocto
vthor has quit [Ping timeout: 255 seconds]
Vonter has quit [Ping timeout: 268 seconds]
Vonter has joined #yocto
Saur_Home69 has quit [Quit: Client closed]
Saur_Home69 has joined #yocto
mbulut has joined #yocto
paulg has joined #yocto
<mischief>
how is license compliance handled with the crate fetcher? IIUC, it.. isn't.
<RP>
sveinse: you can probably use the --runall and/or --runonly options to bitbake and specify package_write_ipk as the task you want
<RP>
khem: you got some replies on gcc's bugzilla :/
Saur_Home69 has quit [Quit: Client closed]
Saur_Home69 has joined #yocto
Saur_Home69 has quit [Client Quit]
Saur_Home69 has joined #yocto
sotaoverride is now known as Guest2391
Guest2391 has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
jmd has quit [Remote host closed the connection]
<sveinse>
RP: What I attempt is to get _all_ packages recursively rdepended on by a packagegroup. The whole point is to collect all ipks for transfer to a package repo.
sotaoverride has joined #yocto
<RP>
sveinse: so did you try bitbake packagegroup --runall package_write_ipk ?
<sveinse>
RP: I'm running it now. OOI, --runall here means to run that task on ALL packages or just the ones depeneded by "packagegroup"?
<RP>
sveinse: just the ones depended upon by packagegroup. See bitbake --help
florian_kc has joined #yocto
Guest28 has joined #yocto
<Guest28>
Hi Yocto Project users. I have a question, wondering if you can suggest. I ran a qemu build. added a layer for testing and wrote simple recipe to build myhello.c the bitbake myhello compiled fine. bitbake image-minimal is taking much longer than expected, it's running something busily;but it shouldn't take more than a few minutes. any suggestions
<Guest28>
for what to check? thank you.!
enok has joined #yocto
Guest28 has quit [Quit: Client closed]
<sveinse>
RP: I needed all ipks recusively, so --runonly didn't work, but --runall seems to do the trick. Thanks a lot.