<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]
<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)]
<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: <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>
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]
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)
<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>
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"
<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.