dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
te_johan has joined #yocto
te_johan has quit [Ping timeout: 245 seconds]
jmiehe has quit [Quit: jmiehe]
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 252 seconds]
jwillikers has quit [Remote host closed the connection]
te_johan has joined #yocto
te_johan has quit [Ping timeout: 245 seconds]
xmn has quit [Quit: ZZZzzz…]
te_johan has joined #yocto
te_johan has quit [Ping timeout: 245 seconds]
amitk has joined #yocto
ykrons_ has quit [*.net *.split]
mischief1 has quit [*.net *.split]
iokill has quit [*.net *.split]
neverpanic has quit [*.net *.split]
iokill has joined #yocto
neverpanic has joined #yocto
ykrons_ has joined #yocto
mischief1 has joined #yocto
mcfrisk has quit [*.net *.split]
zbr has quit [*.net *.split]
zibri has joined #yocto
mcfrisk has joined #yocto
smurray has quit [*.net *.split]
darknighte has quit [*.net *.split]
mckoan|away has quit [*.net *.split]
Chaser has quit [*.net *.split]
r4ge has quit [*.net *.split]
beneth has quit [*.net *.split]
chrysh has quit [*.net *.split]
mfe has quit [*.net *.split]
michaelo has quit [*.net *.split]
mckoan|away has joined #yocto
chrysh has joined #yocto
michaelo has joined #yocto
r4ge has joined #yocto
smurray has joined #yocto
mfe has joined #yocto
darknighte has joined #yocto
darknighte has quit [Changing host]
darknighte has joined #yocto
Chaser has joined #yocto
goliath has joined #yocto
creich_ has joined #yocto
creich has quit [Ping timeout: 245 seconds]
tgamblin_ has joined #yocto
<user_> https://pastebin.com/xKsHDJJB can anyone help me resolving this error,iam trying to build a multimedia image with multilib support
tgamblin has quit [Ping timeout: 250 seconds]
te_johan has joined #yocto
te_johan has quit [Ping timeout: 252 seconds]
mckoan|away is now known as mckoan
frieder has joined #yocto
<mckoan> good morning
Guest9959 has joined #yocto
Guest9959 has quit [Client Quit]
zpfvo has joined #yocto
user_ is now known as user_123
<user_123> Hi
<user_123> I need to enable multilib support in My yoctobuild
creich_ has quit [Quit: Leaving]
creich has joined #yocto
<user_123> I am getting errors when local.conf is modified as suggested by NXP
<user_123> https://pastebin.com/xKsHDJJB i added the error log
zyga-mbp has joined #yocto
rfuentess has joined #yocto
<mckoan> user_123: no clue. Maybe describe what you are doing
<user_123> I am running bitbake imx-image-multimedia
<user_123> I am getting errors
<user_123> Please see https://pastebin.com/xKsHDJJB
<user_123> For error log
<RP> user_123: it is really hard to know what the problem is there. If this has the freescale layer involved you probably need to ask NXP as that layer changes a lot. Have you tried to do this with just plain poky?
<user_123> RP: no, i have not tried with plain poky
leon-anavi has joined #yocto
Guest39 has joined #yocto
<Guest39> Hi, I have a problem with the Freescale ethernet driver, likely dpaa_eth.c. Sometimes I see rotten packets which are not dropped but handled much too late, and such packets have a hardware timestamp in the future then. Is any developer here who wants to see the wireshark recording? I use dunfell for imx8 with a Linux kernel of one year ago.
<qschulz> Guest39: if it's a HW timestamp, i'm pretty sure it's not an issue with Yocto? so might want to contact your vendor (NXP or the OEM using NXP SoCs and/or the one selling the Ethernet PHY)
prabhakarlad has joined #yocto
<Guest39> I measure with tcpdump -i eth0 --time-stamp-precision=nano --time-stamp-type=adapter_unsynced ... and I think this switches HW timestamps on.
<Guest39> Anyway this is how I understand the tcpdump options
bps has quit [Ping timeout: 256 seconds]
Xagen has quit [Ping timeout: 245 seconds]
Xagen has joined #yocto
florian has joined #yocto
<mckoan> Guest39: 99% HW issue
zyga-mbp has quit [Read error: Connection reset by peer]
zyga-mbp has joined #yocto
<Guest39> Is it the PHY which sets HW timestamps on an imx8?
<qschulz> Guest39: I doubt there's an Ethernet PHY embedded in the i.MX8 so it depends on the board you're using
<qschulz> your PHY needs to support it, and the driver driving your PHY needs to support it too
te_johan has joined #yocto
<kanavin> RP: I have reproduced https://bugzilla.yoctoproject.org/show_bug.cgi?id=14342#c20 with master (Setscene tasks in both covered and notcovered errors at the end of build)
<kanavin> RP: can you suggest where I could start with figuring out what goes wrong there?
te_johan has quit [Ping timeout: 265 seconds]
<RP> kanavin: you can look at the patches I previously added to runqueue around this area. Oddly enough I was planning to take a look at that again today
<kanavin> RP: right, if you do that'd be appreciated - a customer is asking me to prioritize this, but I have no idea where to start without a bit of help from you
<RP> kanavin: there isn't a simple/easy way to even explain where to start on that one :/
<kanavin> RP: but it does reproduce fairly easily, so hopefully that helps you
<RP> kanavin: there is a logic glitch somewhere. A task should never be both covered and notcovered, it should be one or the other
<RP> kanavin: the question is therefore which codepath ends up with an item on both
<RP> kanavin: which reproducer did you use?
<kanavin> one in that last comment
<RP> ok, the new one. I've not tried that
<RP> kanavin: I think something in the last patches I merged "regressed" this. Would be interesting to know if this test case worked before that set of patches
<kanavin> RP: I can try if you point me to suspected good commit
<RP> kanavin: I say "regressed" as there is a lot I like about that last patchset, so it is a question of trying to fix whatever cornercase broke rather than revert it
bps has joined #yocto
bps has joined #yocto
<RP> kanavin: basically revert that, I was thinking it was a set but I think it was just the one
SamuelDolt[m] has quit [Quit: You have been kicked for being idle]
<kanavin> RP: will run before&after test on that now
rfuentess has quit [Remote host closed the connection]
bps has quit [Remote host closed the connection]
zyga-mbp has quit [Read error: Connection reset by peer]
zyga has joined #yocto
<kanavin> RP: yes, that is the offending commit
<RP> kanavin: I can confirm it does reproduce here too
obcecado has quit [Quit: leaving]
<kanavin> RP: and gone with the revert
<RP> kanavin: right :/
<RP> kanavin: although it does always print about deadlock first so I think the bug may be that the deadlock code adds to both covered and not covered
<RP> kanavin: so two issues: a) why does it deadlock and should it? b) does the deadlock code do something incorrectly
<kanavin> RP: even before it prints about deferring (and does not with the revert), so I'm not sure if that is an issue too
<RP> kanavin: The deferring would be expected for builds with multiple similar tasks
<wCPO> Is there any convention for where to put recipe? recipes-foo/foo ?
leon-anavi has quit [Quit: Leaving]
<kanavin> wCPO, recipes-domain/foo
<rburton> wCPO: your layer, so you get to define the recipes-* namespaces
<wCPO> kanavin, rburton: naming is always hard :) I will try to stick with recipes-domain/foo
<rburton> your layer will basically enforce that unless you change layer.conf
<RP> kanavin: I think if setscene is present, tasks in the deferred list aren't being made available. The logs are odd
iokill has quit [Ping timeout: 252 seconds]
derRichard has quit [Ping timeout: 245 seconds]
florian_kc has joined #yocto
u1106 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
leon-anavi has joined #yocto
florian_kc has quit [Ping timeout: 265 seconds]
te_johan has joined #yocto
iokill has joined #yocto
derRichard has joined #yocto
<RP> kanavin: I think http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=1cd2b6defa1e77d84cb268571edc1cacf9b57cd1 is a decent workaround
<RP> kanavin: I'm still not quite show whether there is a better fix for this
<wCPO> Is there any reason for some recipe using not following the "Packages should install their configuration files in /usr/lib/tmpfiles.d." convention for tmpfiles.d? (connman, cups, bind)
<RP> wCPO: where is that a quote from?
<wCPO> RP: the manpage: https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html . It is the same for systemd service file
<RP> wCPO: I suspect the guidance from systemd has changed over time and the recipes aren't keeping up
te_johan has quit [Ping timeout: 260 seconds]
<wCPO> RP: I see. I'm coming from Arch Linux where packages must never install anything into /etc/tmpfiles.d or /etc/systemd/system, so just wanted to know if the recipe was out-of-date or I missed something :)
florian_kc has joined #yocto
<rburton> wCPO: if the bug is in the recipe itself, send a patch, otherwise send a bug report/patch upstream
florian_kc has quit [Ping timeout: 252 seconds]
<kanavin> RP: sleep on it?
<RP> kanavin: I'm staring at the code a bit. There is something just slightly out of reach with regard to fixing this
<frosteyes1> Hi folks. I just have an interresting issue while trying to upgrade poky / dunfell on a platform I am working with. The issue is a permission issue.
<frosteyes1> The issue is this - Exception: bb.process.ExecutionError: Execution of '/builds/x/x/x/x/build/tmp/work/x/x/1.0-r0/temp/run.reproducible_final_image_task.34850' failed with exit code 123:
<frosteyes1> With a bunch of Exception: bb.process.ExecutionError: Execution of '/builds/x/x/x/x/build/tmp/work/x/x/1.0-r0/temp/run.reproducible_final_image_task.34850' failed with exit code 123:
<frosteyes1> For the different license files.
<frosteyes1> Notice it is not an issue when building local - but it is an issue when building on our build server.
<frosteyes1> As it was working with the older dunfell release, I have looked into what have changed and found this one liner..
<mihai> frosteyes1: check the equivalent log file log.reproducible_final...
u1106 has joined #yocto
<mihai> exit code 123 smells like pseudo abort
<frosteyes1> mihai: thanks.
<frosteyes1> The commit I linked to was a change from using a single process with find to touch the files, to now using a pipe with xargs and touch.
<frosteyes1> So was wandering if this change also changed how interitance of permission for the touch process with regards to fakeroot / pseudo..
frosteyes1 is now known as frosteyes
<mihai> or arguments list too long
<frosteyes> Good point..
<RP> kanavin: two patches sent to the bitbake list which I think should resolve this
jmiehe has joined #yocto
te_johan has joined #yocto
TrevorWoerner[m] has joined #yocto
beneth has joined #yocto
te_johan has quit [Remote host closed the connection]
te_johan has joined #yocto
florian_kc has joined #yocto
xmn has joined #yocto
manuel1985 has joined #yocto
andy99 has joined #yocto
TrevorWoerner[m] has left #yocto [#yocto]
xicopitz[m] has joined #yocto
<andy99> Hello everyone. can I ask you a question about the kernel-fitimage?
<mihai> andy99: don't ask to ask, just ask :)
jwillikers has joined #yocto
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #yocto
<andy99> :) ok, so ... what's the current status of usage kernel-fitimage including initrams? Why is not part of rootfs? Or even better, how to get the image into rootfs?
tgamblin_ has quit [Quit: Leaving]
tgamblin has joined #yocto
<Guest39> andy99: Is kernel-fitimage one of the available initramfs image types?
<andy99> I think so, because it's being produced into deploydir but not into rootfs
<Guest39> andy99: The initramfs is an image which will be bundled to the kernel image
<andy99> yes, and the kernel is deployed into deploydir instead of rootfs
<Guest39> andy99: The kernel is a file in the boot partition. When the kernel starts as a process it loads the initramfs from its appendix on the kernel image. After the initramfs is loaded a script in the initramfs will load the rootfs. Usually the rootfs is located in another partition.
<andy99> I think, that I know, how the initramfs works :). The main problem is, that this type of image is created after packing, so it's not inside any package. So it can't be installed.
<Guest39> andy99: So I suppose your problem is the initramfs is not bundled to the kernel image, right?
<Guest39> andy99: I don't know if that helps for you since I use core-image-tiny-imageramfs but maybe you can adapt my .conf file:
<Guest39> INITRAMFS_IMAGE = "core-image-tiny-initramfs"
<andy99> no, initramfs is created, but not inside the pckage
<Guest39> VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
<andy99> because it's created afterwards the packaging process
<Guest39> andy99: it's created in the second step but will be bundled to the kernel afterwards
<Guest39> andy99: ... if you configure the bundling properly as shown above
<andy99> Yes, I have the similar setup
<smurray> andy99: one way would be to add it to IMAGE_BOOT_FILES if using the bootimg-partition partition type
<andy99> no, I don't have a boot partition
<andy99> everything is inside rootfs/boot folder
<smurray> afaik you'll need to do up a custom image recipe that depends upon the initramfs and copies it in
<smurray> if you're using wic and /boot has the usual stuff in it, living with a second partition and using bootimg-partition might be simpler
Guest60 has joined #yocto
<andy99> but is it a problem to have it inside rootfs?
paulg has joined #yocto
<qschulz> andy99: so you want your kernel with an initramfs inside the actual initramfs?
<qschulz> There is an egg/chicken issue there
<andy99> no, maybe I didn't write it correctly. Currently I was using the generic kernel. Now I would like to switch into signing one. The bootloader (u-boot) should unpack the initramfs from kernel and verify the signature. Afterwards the device will be booted.
<andy99> so I need to have bundled initramfs inside the kernel. But the artifacts is not being created inside any package, just in the deploy folder.
<andy99> I would like to "take" the artifacts from deploy folder and install it into rootfs
<Guest39> andy99: It makes more sense to put the key files which you need for verifying into the boot partition but not in a folder of the root partition
<andy99> currently I have only one partition
<andy99> Does it mean, to have a separated /boot partition is better idea?
<Guest39> andy99: Separating is a better idea in my opinion, and it works :)
<Guest39> andy99: The bootloader must not mount the whole disk just for running the kernel
<andy99> What I heard, the reason why is "disabled" on the master is, that there was some kind of circular dependency, but I don't have a more info.
<qschulz> your rootfs is not your initramfs is it?
<qschulz> your initramfs is here just to do a dm_verity of the actual rootfs and then switch_root to it?
<Guest60> qschulz: yes, this is the design
<qschulz> Guest60: that was not clear, because the initramfs can be the rootfs (and actually is, just a temporary one in your case)
<qschulz> yeah there was (and maybe still is) a circular dependency
<qschulz> you need a handcrafted kernel-fitimage class
<qschulz> or check what Bartosz from Baylibre tried to upstream a few months ago
<qschulz> I don't remember if it was ever merged but I think not
<Guest39> andy99: I understood your folder with the key files for verifying is in the rootfs. But do you mean that folder is in the initramfs?
<andy99> do you have the link somewhere?
<qschulz> is the issue we ran into
<Guest60> Guest39: the key files are in the initramfs, the signatures are passed in the kernel cmdline from u-boot environment
<qschulz> and that you'll run into
<qschulz> seems like it was merged in meta-security
<qschulz> you probably need other stuff too
<qschulz> this is not using the u-boot script/fitimage mechanism though\
<Guest60> Just to be clear - we don't use dm-verity - problem is that our embedded device can't crash on integrity error during the runtime, so we check on boot.
<Guest60> But maybe we can get some bits and pieces for our implementation.
<qschulz> https://lists.openembedded.org/g/openembedded-core/message/136614?p=,,,20,0,0,0::created,0,bartosz,20,2,0,72497789
manuel1985 has quit [Ping timeout: 260 seconds]
<Guest60> qschulz: Thank you. I'll take a look and contact you in the case of other questions.
<andy99> qschulz: that's the right link ;). But it's from 2020, so no further movement?
<qschulz> andy99: not that I know
<qschulz> Guest60: not personally please :) continue the discussion here, on the mailing list or contact the people who worked on this, they *might* be ok with you contacting thm direclty
<Guest60> qschulz: Ok, i completely understand. I'll proccess the links you provided, and then try the mailing list. Thanks for the info provided so far.
roussinm has joined #yocto
<qschulz> Guest60: my pleasure. Wondering what you have decided to go for instead of dm-verity though :)
<Guest60> Just to check the whole partition signature using dd & openssl. The issue is, that the device does some things very rarely, and when we check the blocks on access, the kernel panic or other indication can occur in a very critical time.
angolini has joined #yocto
camus has quit [Quit: camus]
<Guest39> that's why it's better to load the kernel before that partition becomes actively mounted
sakoman has joined #yocto
<Guest60> Guest39: Crash during the startup is not critical at all, but the crash during runtime can be an issue.
<Guest39> ok, I see
Guest60 has quit [Quit: Client closed]
<smurray> qschulz: the circular dependency issue with dm-verity comes from e.g. needing kernel modules in the rootfs, but the rootfs hash is needed for the initramfs that gets built in the kernel recipe
<qschulz> smurray: we had the circular depenedency because of u-boot script storing the root hash needed by dm_verity stored in the kernel fitimage
<qschulz> except the kernel fitimage is created after the rootfs
<qschulz> (in yocto)
<smurray> qschulz: yes, it's easy to get there with the fitimage
<qschulz> or is it before, eh don't remember, long time ago
<qschulz> it was in the slides I linked :p
<smurray> qschulz: aiui there are some standalone initramfs recipes floating around, but nothing upstreamed
* qschulz hides
<smurray> heh, I've thought about working one up, but have not, so I can't point any fingers
<qschulz> I left the company so can't upstream this anymore as I don't recall any of it
<qschulz> and it would have been probably a bit too hacky
<qschulz> maybe we should ping bartosz/rp again on that topic
<smurray> it's going to become a more common issue as dm-verity shows up on more reqts lists, so sooner or later something will be needed upstream
* qschulz nods
marex has joined #yocto
<andy99> yes, the artifacts are created afterwards
<kanavin> RP: thanks, I am not setting up the previous reported build which presumably regressed due to these fixes, to confirm (or not)
andy99 has quit [Quit: Leaving]
<kanavin> RP: and sadly... yes. Wrote a comment in https://bugzilla.yoctoproject.org/show_bug.cgi?id=14342
<thekappe> hello guys.. I need a hint
<thekappe> I have a kernel recipe append file that install some .bin in ${D}/lib/firmware
Guest39 has quit [Quit: Guest39]
<thekappe> by the way, when the image is built, in build/tmp/work/machine/image/image/ver/rootfs/lib/firmware I have just one .bin file instead of the two of them
<thekappe> the strange thing is that in in build/tmp/work/machine/kernel/ver/image/lib/firmware I have both of them
<qschulz> thekappe: I guess they are split in different packages and you only install one of them?
<qschulz> oe-pkgdata-util find-path '*yourbin.bin'
<thekappe> mmm
<thekappe> you are always right qschulz
camus has joined #yocto
<yannd> in yocto 1.6 we had a basepath= parameter for file: SRC_URI's, and this old manual version keeps coming up in searches, while the parameter does not exist any more and was never mentionned in "Upgrading to ..." sections.
<yannd> did anything replaced it ?
vd has joined #yocto
<kanavin> RP: *not ---> now
<kanavin> (I am *now* setting up...)
<qschulz> yannd: what was the purpose of such a parameter?
dev1990 has quit [Remote host closed the connection]
dev1990 has joined #yocto
<yannd> qschulz: I'd have used it to shorten paths under ${S}. Currently using an absolute file:// URI just copies the full absolute path (under ${WORKDIR} by default)
<yannd> yes, I know absolute file:// is not a good idea, but in some corporate environments that can be the only available way to get to some files
sakoman has quit [Read error: Connection reset by peer]
<yannd> here is how it has to be handled AFAIK: https://stackoverflow.com/a/69091155/6285023
mckoan is now known as mckoan|away
<qschulz> yeah I would have said subdir too
<yannd> my first try after googling for unpack parameters (yes I'm kinda lazy with the docs) was to use both subdir and basepath... until I realized basepath is just doing nothing and I was looking at an outdated doc. Then I googled to know what replaced that parameter and only found that unanswered question ...
<yannd> in fact I'm pretty sure now I already got hit by that old doc item in the past, so my SA answer is as much a reminder to a future self as to anyone else...
<qschulz> yannd: removed in 2016
<qschulz> (Bitbake rev: e659a3b0c2771679057ee3e13cd42e6c62383ff2)
<qschulz> removed from the docs only recently
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
sakoman has joined #yocto
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 260 seconds]
goliath has quit [Quit: SIGSEGV]
prabhakarlad has quit [Quit: Client closed]
zpfvo has quit [Quit: Leaving.]
<RP> kanavin: Shame it regresses the other test case :(
<RP> kanavin: that is quite frustrating
<smurray> oh boy, OpenSSL 3.0 has officially released
cocoJoe has quit [Quit: Client closed]
<RP> kanavin: hmm, I do understand what breaks in that other test case
<fray> smurray thanks for the heads up..
<RP> smurray: should we try and get that into 3.4? :)
goliath has joined #yocto
<smurray> RP: heh, definitely not
<RP> smurray: I don't think I could take it (and more seriously, the user projects need to adapt first)
<smurray> RP: yeah, I'll be curious to see how quick Fedora jumps on it
<smurray> RP: I suspect the bigger pain comes whenever they do a release that drops the piles of APIs they've marked as deprecated in 3.0
frieder has quit [Remote host closed the connection]
whuang0389 has joined #yocto
<RP> wCPO: Not sure I understand your question?
<wCPO> RP: it is your mail right? You linked the same commit twice
<RP> wCPO: ah,yes, I did mess that up
<RP> wCPO: that commit broke things iirc and the fix was https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=rcu/next&id=dc87740c8a6806bd2162bfb441770e4e53be5601
<wCPO> RP: thanks, we started seeing some "rcu_preempt detected stalls" recently in Arch Linux CI. Not sure it is related tho
<RP> wCPO: can have many causes, if it locks the system up entirely this one could be a cause though
robbawebba has joined #yocto
prabhakarlad has joined #yocto
xmn has quit [Ping timeout: 252 seconds]
<RP> kanavin: ok, I think my fix was the right idea, wrong function: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=e6ec662c597cdad358f08a9ec9a5effea28978d1
<RP> kanavin: master-next updated
<robbawebba> Hello, I have a question about premirrors, specifically using the "own-mirrors" bbclass. I noticed that the DL_DIR contains the source code archives as well as a .done file for each archive. Should the .done files be served from a mirror along with the actual source code archives, or will the .done file be created by the client after downloading from the mirror?
<kergoth> robbawebba: the latter
<fray> .done files won't cause failures from the mirror server, but they also don't do anything. I usually remove them from the server
<whuang0389> I need to provide my own hostapd.conf file
<whuang0389> whats the preferred way of doing it?
<kanavin> RP: thanks, I'll try that once I get out of cycling kit and shower ;)
<RP> kanavin: I think the test case in c13 will throw "errors" but I'm not sure these new ones are the fault of runqueue
<kanavin> RP: I'll try. And gah, that Damian guy on bitbake-devel :-/
<kanavin> RP: meanwhile, I have some results from lttng-tools 10x ptests
vd has quit [Quit: Client closed]
vd has joined #yocto
<RP> kanavin: I think I understand what is going on with the new errors. Trying to decide if I want to fix the sstate hashes or runqueue further
<robbawebba> Thanks kergoth and fray :)
<robbawebba> whuang0389: The preferred way of doing it should be creating your own bbappend file for the hostapd package. In this bbappend file, you'll want to append the path to your custom file to the FILES variable, and you'll probably need a custom do_install_append function to overwrite the default config.
whuang0389 has quit [Quit: Client closed]
<robbawebba> whoops, I said FILES, but I meant SRC_URI
<kanavin> RP: let me know when you have something you'd like me to test
angolini has quit [Quit: Connection closed for inactivity]
jmiehe has quit [Ping timeout: 260 seconds]
zyga has quit [Ping timeout: 252 seconds]
zyga-mbp has joined #yocto
<RP> kanavin: master-next has a tweaked patch which is ready for wider testing again. I'll continue to run local tests too
zyga-mbp has quit [Read error: Connection reset by peer]
zyga-mbp has joined #yocto
<abelloni> RP: I just sent the previous one to the AB, should I restart ?
<abelloni> well, 42 minutes ago
whuang0389 has joined #yocto
BobPungartnik has joined #yocto
BobPungartnik has quit [Client Quit]
<whuang0389> robbawebba thanks, it worked! I guess Yocto wasn't happy when I overwrote the hostapd.conf file with the one in application recipe
camus has quit [Quit: camus]
<RP> abelloni: please
<RP> abelloni: it would be worth testing these two properly as my local testing shows they're better
leon-anavi has quit [Quit: Leaving]
<vd> Is it OK to use the deploy class to copy a final image to a specific (CI/CD) directory (not DEPLOYDIR/DEPLOY_DIR_IMAGE)?
goliath has quit [Quit: SIGSEGV]
Dracos-Carazza has quit [Quit: ZNC 1.8.2 - https://znc.in]
Dracos-Carazza has joined #yocto
<JPEW> vd: You might have touble with task reruns if you try to do that
<JPEW> I wouldn't recommend it at least
<vd> JPEW so I shouldn't inherit the deploy class?
RobertBerger has quit [Ping timeout: 252 seconds]
<JPEW> vd: You cause use it, but it might cause some issues if you don't deploy to DEPLOYDIR
Guest98 has joined #yocto
<JPEW> vd: What is it you want to accomplish?
Guest98 has quit [Client Quit]
<vd> JPEW a bit like you alias deploy whisk class, I need the CI/CD to copy the interesting output files (not all of them) to a different local directory
goliath has joined #yocto
<JPEW> vd: Copy files out of deploydir?
<JPEW> or DEPLOY_DIR_IMAGE more specifically?
<JPEW> My first thought would be "Do you really need to run that as a bitbake task for some reason?" It seems like your CI/CD could have a post-build script that copies the output from deploy dir to where ever you want it
<JPEW> (But I might be misunderstanding what you are trying to do)
<vd> out of DEPLOY_DIR_IMAGE. I could simply upload DEPLOY_DIR_IMAGE but there is so much image files we don't need in there, it's confusing. I only need to copy a few final image files to a locally mounted server directory.
<vd> good question. The thing is that only bitbake knows about specific path for a multiconfig (e.g. DEPLOY_DIR_IMAGE, BB_CURRENT_MC, etc.)
<JPEW> vd: Ah, ya, that's a common problem; the best solution (that I've found) is to fix it by having a convention for how your files and directories are named; the is effectively what whisk does, although it has the convenience of setting some variables for you to make it a little easier.
<JPEW> vd: But, there is another way; you can actually ask bitbake the value of those variables. Sort of like you do manually with `bitbake -e`
<JPEW> vd: I think there is a command or library that can be used to query that programatically?
<RP> JPEW: bitbake-getvar ?
<RP> or tinfoil
florian has joined #yocto
<vd> hum, I donno. I have a dummy recipe to group all interesting images, and I build this dummy recipe for all my multiconfig (these are build profiles). I think the simplest is still to have a simple additional task in this dummy recipe to copy its images to a custom directory.
creich_ has joined #yocto
creich has quit [Ping timeout: 252 seconds]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 252 seconds]
jmiehe has joined #yocto
whuang0389 has quit [Quit: Client closed]
whuang0389 has joined #yocto
xmn has joined #yocto
whuang0389 has quit [Client Quit]
jmiehe has quit [Quit: jmiehe]
amitk_ has quit [Quit: leaving]
tlwoerner has quit [Quit: Leaving]
otavio has quit [Remote host closed the connection]
otavio has joined #yocto
prabhakarlad has quit [Quit: Client closed]
florian has quit [Ping timeout: 260 seconds]
yannd has quit [Ping timeout: 240 seconds]
yannd has joined #yocto
yannd has quit [Ping timeout: 260 seconds]
yannd has joined #yocto