ChanServ changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2021.11) Nov 30 - Dec 2, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec
dev1990 has quit [Quit: Konversation terminated!]
florian_kc has joined #yocto
Tokamak has quit [Ping timeout: 240 seconds]
Tokamak has joined #yocto
Tokamak has quit [Ping timeout: 268 seconds]
Tokamak_ has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
<vd33> is there a way to avoid creating a partition table with wic?
<JPEW> vd33 I don't know if you can avoid the whole table, but you can make an entry so it is not added to the table... the option is notable I think
<vd33> JPEW yeah no I'd like to create a image for the boot partition, so far I'm achieving this by using a wks file with the boot part only and adding a task to skip the 512 first bytes in the produced wic image.
<JPEW> vd33 your boot code (IPL?) has to be in the first sector?
<vd33> JPEW no, I'm using an update mechanism for the boot partition which requires an image of the partition. So the boot.vfat image what wic doesn't provide you ;-)
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
bluelightning has quit [Remote host closed the connection]
bluelightning has joined #yocto
tlwoerner has joined #yocto
codavi has quit [Ping timeout: 240 seconds]
<moto-timo> RP: it's late and this is untested, but here's the workaround I'm testing for the problem at hand https://github.com/moto-timo/meta-dotnet/commit/2eeb6776c6d34ba9909d65daef4d3831e518b46b
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
pgowda_ has joined #yocto
davidinux has joined #yocto
ziga has joined #yocto
Sunny has quit [Ping timeout: 256 seconds]
GNUmoon has quit [Ping timeout: 276 seconds]
mvlad has joined #yocto
Tokamak_ has quit [Ping timeout: 268 seconds]
Tokamak has joined #yocto
Tokamak_ has joined #yocto
Tokamak has quit [Ping timeout: 256 seconds]
camus has quit [Quit: camus]
camus has joined #yocto
GNUmoon has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
Tokamak_ has quit [Ping timeout: 240 seconds]
kiran_ has joined #yocto
kiran_ has quit [Remote host closed the connection]
Tokamak has joined #yocto
rob_w has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
Tokamak has quit [Ping timeout: 268 seconds]
Tokamak has joined #yocto
zpfvo has joined #yocto
leon-anavi has joined #yocto
vd33 has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
mckoan|away is now known as mckoan
olani has quit [Ping timeout: 268 seconds]
xmn has quit [Quit: ZZZzzz…]
Schlumpf has joined #yocto
Schlumpf has quit [Client Quit]
Schlumpf has joined #yocto
prabhakarlad has joined #yocto
<JosefHolzmayrThe> yo dudX
<RP> moto-timo: seems reasonable
Ad0 has quit [Ping timeout: 268 seconds]
<rburton> moto-timo: presumably fixing dotnet isn't an option here
Ad0 has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
snikulov has joined #yocto
leon-anavi has quit [Quit: Leaving]
<rburton> RP: why does bitbake-selftest have a list of tests to run
<RP> rburton: no idea
<rburton> should be easily removed
<rburton> hm it looks like its non-trivial to setup a task inside bitbake-selftest
<RP> rburton: aren't there tests which effectively do builds?
<rburton> i was hoping it wouldn't be too much faff to construct a task in code and run it
mariusz has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
florian has joined #yocto
zpfvo has joined #yocto
<RP> rburton: since you're testing the network change, you'd need to do it in a new process. For that you'll need the bitbake worker overhead?
<rburton> hm good point :)
<RP> well, I'm guessing you are
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
olani has joined #yocto
lucaceresoli has joined #yocto
rob_w has quit [Ping timeout: 240 seconds]
rob_w has joined #yocto
<dacav> hi. I've done some damage to the tmp/deploy directory. Now building my image recipe fails randomly. I would say that a git clean and start over would fix it, but I don't want to waste hours. I'm thikining of erasing only the tmp/work/$machine directory, while keeping x86_64-linux/ (the idea is to avoid re-building native tools, at least). Would it work? Would you suggest anything better?
<JosefHolzmayrThe> dacav: just remove tmp
<dacav> 24 gigabytes of tmp
<JosefHolzmayrThe> dacav: if you keep downloads and sstate, rebuilding tmp should be a matter of minutes. yet if sstate is damaged, then you're in for trouble anyways.
<JosefHolzmayrThe> ya so what?
<dacav> ah, if you say it is minutes, that's fine
<JosefHolzmayrThe> just make sure you keep downloads and sstate.
<dacav> I kept DOWNLOADSDIR away :)
<dacav> Thanks JosefHolzmayrThe. I suspect I killed sstate while trying to clean and redo minimally... but hey, at this point I think I'm screwed anyway :)
<dacav> But 18 gigabytes of downloads, at least, are spared
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
rob_w has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
coldspark29 has joined #yocto
Nathan80 has joined #yocto
Nathan80 has quit [Quit: Ping timeout (120 seconds)]
goliath has joined #yocto
Nathan62 has joined #yocto
<Nathan62> Hello, I'm having trouble with ptest. I've followed https://docs.yoctoproject.org/dev-manual/common-tasks.html#testing-packages-with-ptest
<Nathan62> I create a distro with `DISTRO_FEATURES_append = "ptest"` and added `ptest-pkgs` to my `EXTRA_IMAGE_FEATURES` in local.conf
<Nathan62> building my image resulted in a bunch of ptest enabled recipes being rebuilt
<Nathan62> but `ptest-runner` in my image doesn't find any tests to run.
<Nathan62> Do you have any tips on what to look for?
dtometzki has quit [Quit: ZNC 1.8.2 - https://znc.in]
dtometzki has joined #yocto
<dacav> rburton: yesterday you mentioned that I should probably IMAGE_INSTALL:append kexec instead of kexec-tools. That was ineffective too, I'm afraid. Actually, I lied a little in saying that I was using :append. I'm actually adding kexec/kexec-tools to the existing IMAGE_INSTALL += "..." definition made by a colleague of mine. Does the operator matter?
<rburton> the only thing that matters is the end result, so use bitbake -e imagename and check that kexec ends up in IMAGE_INSTALL
<dacav> - it should not, by intuition, yet it is said explicitly to use :append in the reference manual
<dacav> Ah, this is interesting: I could not find `IMAGE_INSTALL` in the output of bitbake -e
<dacav> it looks ... commented?
<rburton> the output is sh-ish, so ignore that
<dacav> yes, I usually grep for ^WHATEVER
<dacav> bitbake -e | grep ^IMAGE_INSTALL → no lines
<dacav> ah, idiot me, I should provide the name of the recipe
<dacav> Anyway, it does appear to IMAGE_INSTALL, yet it does not end up under tmp/work/$machine/ as I would expect (unless I build it explicitly with bitbake kexec). Both ways, it won't be in the final image. If anything, I've ruled out IMAGE_INSTALL. Thanks.
Nathan62 has quit [Quit: Ping timeout (120 seconds)]
tgamblin has joined #yocto
oberonc has joined #yocto
<oberonc> I know paho-mqtt-c has a recipe, how can I tell if paco mqtt c++ has a recipe too ?
<dacav> oberonc: bitbake-layers show-recipes maybe?
<oberonc> I did that, but it only lists paho-mqtt-c
<oberonc> even though https://layers.openembedded.org/layerindex/branch/master/recipes/?q=paho-mqtt-c lists paho-mqtt-cpp also as supported by meta-oe
<dacav> oberonc: <disclaimer, I'm very new to yocto> ...could it be a matter of version?
<oberonc> I have no idea
zpfvo has quit [Ping timeout: 250 seconds]
<dacav> that is, the recipe you saw on layers.openembedded.org is not compatible with your current version
zpfvo has joined #yocto
<smurray> oberonc: AFAICT the paho-mqtt-cpp recipe was added in Nov to the master branch in meta-oe, you're not going to see it on any other branch
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
codavi has joined #yocto
ar__ has joined #yocto
sakoman has joined #yocto
codavi has quit [Ping timeout: 240 seconds]
<coldspark29[m]> @qschulz Is it only possible to run setup Pyrex after having run ./setup-environment once?
<coldspark29[m]> I just tried to set it up for a new build environment and it doesn't work without having run that first
<coldspark29[m]> I thought it would basically accomplish the same
<coldspark29[m]> But the bblayers.conf is not complete
<coldspark29[m]> Maybe my setup script needs to be refined
sakoman has quit [Ping timeout: 240 seconds]
coldspark29 has quit [Remote host closed the connection]
coldspark29 has joined #yocto
<coldspark29[m]> Another problem is that we host a lot of stuff on our own server, which needs and SSH key entry. So the Pyrex containers can't access those repositories
sakoman has joined #yocto
<JPEW> coldspark29[m]: You have to map the keys into the container that is needed
<oberonc> I got the paho-mqtt-cpp recipe ad tried ti run it using bitbake paho-mqtt-cpp, I get this error:
<oberonc> ERROR: paho-mqtt-cpp-1.2.0-r0 do_package: QA Issue: paho-mqtt-cpp: Files/directories were installed but not shipped in any package:
<oberonc>   /usr/lib
<oberonc>   /usr/lib/cmake
<oberonc>   /usr/lib/cmake/PahoMqttCpp
<oberonc>   /usr/lib/cmake/PahoMqttCpp/PahoMqttCppTargets-noconfig.cmake
<oberonc>   /usr/lib/cmake/PahoMqttCpp/FindPahoMqttC.cmake
<oberonc>   /usr/lib/cmake/PahoMqttCpp/PahoMqttCppConfigVersion.cmake
<oberonc>   /usr/lib/cmake/PahoMqttCpp/PahoMqttCppTargets.cmake
<oberonc>   /usr/lib/cmake/PahoMqttCpp/PahoMqttCppConfig.cmake
<oberonc> Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
<oberonc> paho-mqtt-cpp: 8 installed and not shipped files. [installed-vs-shipped]
<oberonc> ERROR: paho-mqtt-cpp-1.2.0-r0 do_package: Fatal QA errors found, failing task.
<oberonc> what gives ?
<coldspark29[m]> JPEW: Ah nice thanks
jpuhlman has quit [Remote host closed the connection]
jpuhlman has joined #yocto
<coldspark29[m]> @JPEW Any ideas about the setup script as well? I load pyrex into my Yocto folder, which has the following structure then... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/7e91bf7b2021e057b40838c1401671d8c9c00ce5)
<coldspark29[m]> s/then//, s/build//, s/pyrex pyrex-init-build-env pyrex.ini//
<coldspark29[m]> s/then//, s/build//, s/pyrex pyrex-init-build-env pyrex.ini//
<coldspark29[m]> s/then//, s/build//, s/pyrex pyrex-init-build-env pyrex.ini//
<coldspark29[m]> Problem is I can only run Pyrex once I have run ./setup-environment once
zpfvo has quit [Ping timeout: 240 seconds]
<JPEW> coldspark29[m]: "My Script" is setup-environment ?
zpfvo has joined #yocto
<coldspark29[m]> Hmm I guess it is something Freescale-related
<coldspark29[m]> Will probably have to tune the script for Pyrex
<JPEW> coldspark29[m]: You can roll the pyrex setup into setup-environment
<JPEW> coldspark29[m]: (and probably should)
<coldspark29[m]> JPEW: For now I would just keep it this way, because a few things like `devtool edit-recipe` are not working
zpfvo has quit [Ping timeout: 268 seconds]
<coldspark29[m]> So sometimes I would still need to use the normal Yocto environment
zpfvo has joined #yocto
<JPEW> I think you would want something like https://www.irccloud.com/pastebin/whAMTCFd/
jpuhlman_ has joined #yocto
jpuhlman is now known as Guest7254
Guest7254 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
jpuhlman_ is now known as jpuhlman
<JPEW> coldspark29[m]: Ah. I'm confused about which file you are showing me the contents of in your previous post
<coldspark29[m]> JPEW: Are you on IRC?
<JPEW> coldspark29[m]: yes
<coldspark29[m]> Yeah pasting code on IRC is not nice
<JPEW> I got the code; I just don't know which file "my script" is :)
<JPEW> It doesn't really matter too much I guess
<coldspark29[m]> Oh those are just the commands I use to setup the environment
<coldspark29[m]> But I guess all of that is correct
<JPEW> coldspark29[m]: Looks correct to me
<coldspark29[m]> I would just need to edit the script from Freescale for Pyrex
<JPEW> Ya. *usually* you would check in pyrex.ini so that everyone uses the same one
<coldspark29[m]> I also made an issue on Github for the `devtool edit-recpipe` feature
<JPEW> And you can setup the init script so that it does the environment setup automatically
<coldspark29[m]> Yeah I need to include the .ssh folder etc.
<coldspark29[m]> Ah I could also mount my .vim folder and .vimrc I guess
<JPEW> coldspark29[m]: Ya, that might work
<coldspark29[m]> Is Vim included in the container?
<coldspark29[m]> Think it was missing and that is why `devtool edit-recipe` didn't work
<JPEW> I'm a little leery of passing the editor in.... it's not the same environment, and I'm not sure I want to set the precedence that any random "editor" will work inside the container
<JPEW> The whole point of Pyrex is that you can use whatever host environment/editor/etc you want :)
<coldspark29[m]> Yeah but the command should work
<coldspark29[m]> Since everyone has his own EDITOR in env, all those should be supported
<JPEW> If we want it to just "work" we should hardcode EDITOR to nano or something inside the container
<coldspark29[m]> Or yeah that would work, but wouldn't satisfy me
<JPEW> Like I said, setting the precdence that the users editor works in the in container is..... not a road I want to go down
<coldspark29[m]> I would just like be able to follow Joseph's tutorial for example
<coldspark29[m]> And he uses those commands
<JPEW> "An editor" is fine; the users specific editor with all their settings.... no
<JPEW> Sure
<coldspark29[m]> Why not?
<JPEW> It's really hard to get that all configured identically
<JPEW> For example, if I'm using Pyrex to build old Yocto on Ubuntu 16.04... it's just not going to go well
<JPEW> Do we have to keep the latest version of every possible EDITOR in every container?
<coldspark29[m]> Hmm should I mount my /usr/bin/vim then?
<JPEW> It probably won't run due to library dependencies
<coldspark29[m]> Whole /usr/bin would be a bit much I guess
<JPEW> (or it might happen to work if you host is close enough to the contianer)
<JPEW> No, don't do /usr/bin
<coldspark29[m]> Yeah but you could mount those libraries as well. Make some scripts to easily mount those editors from the host
<JPEW> At that point, don't use Pyrex :)
<JPEW> Like I said, I *do* want it to work, but I'm not sure what the best way to go about that is yet
<JPEW> We've fixed previous things like this by excluding things from running inside the container (e.g. qemu)
<coldspark29[m]> Yeah I think mounting the libraries will be as mess on second thought
<coldspark29[m]> They will substitute the older libraries of the container and break things
<JPEW> But... we can't do that here because its a subcommand, and I don't think we can exclude all of devtool as it would break other things it does
<coldspark29[m]> Maybe you could mount appimages
<JPEW> Possibly, I don't know enough about them
<coldspark29[m]> or snaps
<coldspark29[m]> Well the only viable solution would be to mount an isolated application image into the container
Schlumpf has quit [Ping timeout: 256 seconds]
<coldspark29[m]> Else stuff will break
<JPEW> *If* we have to run an editor in the container
<coldspark29[m]> But this will also not be easily done I get it
<JPEW> The other problem is that we don't do anything to setup graphical in Purex
<coldspark29[m]> devtool is quite convenient
<coldspark29[m]> I don't need it, but it is nice
<JPEW> Sure; Like I said I would prefer to make it so that `devtool edit-recipe` just runs outside the container
<JPEW> I *think* that will work better
<coldspark29[m]> Yeah but containers are not supposed to have access to the host
<JPEW> Correct
<coldspark29[m]> I read somewhere that it is possible with named pipes somewhere
<coldspark29[m]> s/somewhere/somehow/
<JPEW> Pyrex intercepts commands you run and decides if it should run them inside the contianer or outside
<JPEW> It's not breaking out of the container, it not running it there in the first place
<coldspark29[m]> Yeah it is tricky
<coldspark29[m]> I think adding all the editors wouldn't be so bad. I wouldn't mind the version of the editor that much. I would also not need all of my vim plugins. Would just nice to have the same editor.
<coldspark29[m]> But well, I will leave it for now
<JPEW> You can test this by editing pyrex.ini to pass EDITOR
xmn has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
oberonc has quit [Quit: Client closed]
<coldspark29[m]> It does propagate it, but there is no vim in the container so
<JPEW> coldspark29[m]: Ah
<coldspark29[m]> I would be perfectly fine with the default, which is vi, but I guess that would be not great for users that don't know the vi commands
<coldspark29[m]> Many of my colleaques say the only vi command they know is how to get out ^^
<JPEW> coldspark29[m]: Right
<coldspark29[m]> Is there a way I could install my favorite editor to the containers myself?
<JPEW> You'd have to build your own container, but ya
<JPEW> Hang, on let me find the documentation...
<JPEW> Then you can change the Dockerfile and add whatever you want
Borimo has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
<coldspark29[m]> Will look into it tomorrow maybe
<coldspark29[m]> Thanks
Borimo has joined #yocto
mariusz has quit [Ping timeout: 240 seconds]
vd33 has joined #yocto
<vd33> apparemently there is a maximum image size which causes me an error
<vd33> mine in 108+ mo because I have lots of data in the boot partition
<vd33> 180*
<vd33> is there a way to allow such big image to be created?
<fabatera[m]> Trying to build gRPC helloworld I'm getting:
<fabatera[m]> Solved after adding `RPROVIDES_${PN} += "libhw_grpc_proto.so()(64bit)"`
<fabatera[m]> But it looks strange. Any comment?
<fabatera[m]> `ERROR: mygrpc-1.0+git999-r0 do_package_qa: QA Issue: /opt/greeter_server contained in package mygrpc requires libhw_grpc_proto.so()(64bit), but no providers found in RDEPENDS_mygrpc? [file-rdeps]`
<fabatera[m]> -> The .so file is built within helloworld
tperrot[m] has joined #yocto
Minvera has joined #yocto
tperrot[m] has left #yocto [#yocto]
tperrot[m] has joined #yocto
florian has quit [Quit: Ex-Chat]
<rburton> vd33: whats the error?
florian_kc has quit [Ping timeout: 256 seconds]
tperrot[m] has left #yocto [#yocto]
Vonter has quit [Quit: WeeChat 3.4]
lucaceresoli has quit [Remote host closed the connection]
Konsgn has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
Net147 has quit [Ping timeout: 260 seconds]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
<vd33> rburton "image size exceeds allowed size of X" or something, I'll try to get it back after testing compression
zpfvo has quit [Quit: Leaving.]
<vd33> rburton: "Actual rootfs size (187439 kB) is larger than allowed size 131072 kB"
<rburton> from what?
<rburton> meta/conf/bitbake.conf:INITRAMFS_MAXSIZE ??= "131072"
<rburton> that?
<rburton> assuming this is a initramfs
<rburton> you're not saying what type of image, or what stage, so it's hard to comment
ziga has quit [Ping timeout: 240 seconds]
<vd33> rburton: hard to say. I've enabled buildhistory and the rootfs image contains qtwebengine which is 110800 KiB already...
mckoan is now known as mckoan|away
Tokamak has quit [Ping timeout: 256 seconds]
Tokamak has joined #yocto
dtometzki has quit [Quit: ZNC 1.8.2 - https://znc.in]
dtometzki has joined #yocto
<rfs613> I can get a list of all packages (and versions) using 'bitbake -s'; is there a way to restrict this to package which are actually enabled for a given image?
<rfs613> (I tried doing 'bitbake -e <image> | grep ^PACKAGES' but this did not produce the list I was expecting.
dtometzki has quit [Quit: ZNC 1.8.2 - https://znc.in]
dtometzki has joined #yocto
dti has joined #yocto
dtometzki has quit [Read error: Connection reset by peer]
<vd33> rburton: the wrong WKS_FILE was deduced, thanks.
<vd33> can you pass variables from the image recipe to the .wks file?
<vd33> yes, .wks.in files
snikulov has quit [Remote host closed the connection]
snikulov has joined #yocto
snikulov has quit [Remote host closed the connection]
geoffhp has joined #yocto
florian_kc has joined #yocto
vd33 has quit [Quit: Client closed]
vd33 has joined #yocto
mvlad_ has joined #yocto
mvlad has quit [Ping timeout: 260 seconds]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
florian_kc has quit [Ping timeout: 240 seconds]
GNUmoon has quit [Ping timeout: 276 seconds]
Tokamak has quit [Ping timeout: 240 seconds]
sakoman has quit [Quit: Leaving.]
Tokamak has joined #yocto
LocutusOfBorg has quit [Quit: ZNC 1.8.2+deb1+bionic2 - https://znc.in]
LocutusOfBorg has joined #yocto
mvlad_ has quit [Remote host closed the connection]
florian_kc has joined #yocto
mariusz has joined #yocto
Tokamak has quit [Ping timeout: 256 seconds]
lucaceresoli has joined #yocto
Tokamak has joined #yocto
dev1990 has joined #yocto
GNUmoon has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
Minvera has quit [Quit: Leaving]
florian_kc has quit [Ping timeout: 240 seconds]
<mcfrisk> ¶
lucaceresoli has quit [Ping timeout: 240 seconds]
mariusz has quit [Ping timeout: 256 seconds]
sakoman has joined #yocto
Tokamak has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
Tokamak has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]